From noreply at sourceforge.net Tue Aug 1 00:33:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Jul 2006 15:33:02 -0700 Subject: [ python-Bugs-1501291 ] python/ncurses bug in 2.4.3 with extended ascii Message-ID: Bugs item #1501291, was opened at 2006-06-05 16:34 Message generated for change (Comment added) made by unixops1234 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501291&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: UnixOps (unixops1234) Assigned to: Nobody/Anonymous (nobody) Summary: python/ncurses bug in 2.4.3 with extended ascii Initial Comment: There is a problem displaying extended ascii characters in ncurses through python, which does not exist in versions prior to 2.4.2. I am running RedHat Enterprise Linux WS 3 with updated patches, using the system version of ncurses (ncurses-5.3-9.4 and devel). When building a vanilla python 2.4.3 from source, printing extended ascii characters in ncurses fails: $ cat test.py import curses screen = curses.initscr() screen.addstr("\x80") screen.getch() curses.endwin() $ python test.py Traceback (most recent call last):hon test.py File "test.py", line 5, in ? screen.addstr("\x80") _curses.error: addstr() returned ERR This should produce a blank ncurses screen, rather than the addstr() error. I've been able to confirm that it works with python 2.4.2 and earlier. To ensure that ncurses was able to display the character, I wrote this test C program: $ cat test.c #include int main() { initscr(); int rtn = addstr("\x80"); getch(); endwin(); printf("The return value was %d.\n",rtn); return 0; } $ gcc test.c -o test -lncurses $ ./test This works just fine, so I think the problem lies somewhere in the python interface to ncurses. Python can print this character without errors when not using ncurses. Perhaps ncurses is expecting different initialization than python is providing. I've also tested this on a RedHat WS 4 machine, where it works just fine. This system is running ncurses-5.4-13 and ncurses-devel-5.4-13. It seems the newer release of python has changed something that the older versions of ncurses are unable to handle. Can this be fixed in _cursesmodule.c? ---------------------------------------------------------------------- >Comment By: UnixOps (unixops1234) Date: 2006-07-31 16:33 Message: Logged In: YES user_id=1534776 akuchling, thanks. Your suggestion worked. I added import locale locale.setlocale(locale.LC_ALL, 'en_US') to the beginning of my test.py script and it correctly displayed the funky character. loewis, what I meant is that the C code correctly printed a strange character instead of crashing with a curses error message. The panelw patch is not needed after all. The test.py script also works just fine if I build python against ncurses 5.5 instead of 5.4. Thank you both for your help with this. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-07-26 14:39 Message: Logged In: YES user_id=21627 unixops1234, can you please explain what "works just fine" for the C code means? \x80 is not a meaningful character for the terminal. On my system (Debian with ncurses 5.5, locale de_DE.UTF-8, konsole), the program prints something, namely the characters ~@ ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-07-26 12:45 Message: Logged In: YES user_id=11375 The ncurses 5.5 changelog, currently at http://www.gnu.org/software/ncurses/ncurses.html, contains this entry: * use setlocale() to query the program's current locale rather than using getenv(). This supports applications which rely upon legacy treatment of 8-bit characters when the locale is not initialized. So maybe this is a problem in ncurses 5.4 that can be avoided if your Python script calls 'locale.setlocale("")'. ---------------------------------------------------------------------- Comment By: UnixOps (unixops1234) Date: 2006-06-08 14:02 Message: Logged In: YES user_id=1534776 I tried recompiling Python with the patch from bug #1464056 that fixes the panelw linking in _curses_panel.so. It now properly links with libpanelw instead of libpanel, but the original problem persists. I still get "_curses.error: addstr() returned ERR" when running the test code. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-08 11:58 Message: Logged In: YES user_id=21627 I doubt it can be fixed in _cursesmodule. Notice that Python links with ncursesw now, not with ncurses anymore. There is a bug in 2.4.3 which links, apparently incorrectly, with panel instead of panelw. Try changing that and see whether it helps. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1501291&group_id=5470 From noreply at sourceforge.net Tue Aug 1 00:33:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Jul 2006 15:33:31 -0700 Subject: [ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails Message-ID: Bugs item #1531862, was opened at 2006-07-31 16:53 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 Please note that this 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: John A Meinel (jfmeinel) >Assigned to: Peter ?strand (astrand) Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails Initial Comment: I'm currently using subprocess.Popen() to run a command, and I allow the caller to specify where the output should go. One valid output is to send it to sys.stdout (fileno == 1) The subprocess module seems to unconditionally close stdout if a file handle is passed (even if it stdout). Compare: python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'])" versus python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)" or even python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=1)" The first one prints 'hello' as expected. The latter two give an error: echo: write error: Bad file descriptor Attached is a possible patch to subprocess.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 From noreply at sourceforge.net Tue Aug 1 01:49:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Jul 2006 16:49:47 -0700 Subject: [ python-Bugs-1506951 ] pydoc fails on package in ZIP archive Message-ID: Bugs item #1506951, was opened at 2006-06-16 00:07 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506951&group_id=5470 Please note that this 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: Christopher Dunn (christopherdunn) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc fails on package in ZIP archive Initial Comment: I have Foo/__init__.py and Foo/bar.py in a ZIP archive, test.zip, which is in the PYTHONPATH. pydoc works on Foo.bar, but fails on package Foo. % pydoc Foo Traceback (most recent call last): File "~/bin/pydoc", line 5, in ? pydoc.cli() File "../python-2.4/lib/python2.4/pydoc.py", line 2228, in cli help.help(arg) File "../python-2.4/lib/python2.4/pydoc.py", line 1682, in help elif request: doc(request, 'Help on %s:') File "../python-2.4/lib/python2.4/pydoc.py", line 1468, in doc pager(title % desc + '\n\n' + text.document(object, name)) File "../python-2.4/lib/python2.4/pydoc.py", line 296, in document if inspect.ismodule(object): return self.docmodule(*args) File "../python-2.4/lib/python2.4/pydoc.py", line 1053, in docmodule for file in os.listdir(object.__path__[0]): OSError: [Errno 20] Not a directory: 'test.zip/Foo' ---------------------------------------------------------------------- Comment By: Žiga Seilnacht (zseil) Date: 2006-08-01 01:49 Message: Logged In: YES user_id=1326842 This is fixed in the 2.5 release. The details of the fix are quite involved, so it is unlikely that it will be backported. See revision 45510 for details: http://mail.python.org/pipermail/python-checkins/2006-April/051452.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506951&group_id=5470 From noreply at sourceforge.net Tue Aug 1 08:20:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Jul 2006 23:20:29 -0700 Subject: [ python-Bugs-215126 ] Over restricted type checking on eval() function Message-ID: Bugs item #215126, was opened at 2000-09-22 19:36 Message generated for change (Comment added) made by aaiyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=215126&group_id=5470 Please note that this 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: Feature Request Status: Closed Resolution: None Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Armin Rigo (arigo) Summary: Over restricted type checking on eval() function Initial Comment: The built-in function eval() takes a string argument and a dictionary. The second argument should allow any instance which defines __getitem__ as opposed to just dictionaries. The following example creates a type error: eval, argument 2: expected dictionary, instance found class SpreadSheet: _cells = {} def __setitem__( self, key, formula ): self._cells[key] = formula def __getitem__( self, key ): return eval( self._cells[key], self ) ss = SpreadSheet() ss['a1'] = '5' ss['a2'] = 'a1*5' ss['a2'] ---------------------------------------------------------------------- Comment By: Anand Aiyer (aaiyer) Date: 2006-08-01 06:20 Message: Logged In: YES user_id=1554342 There is a missing PyErr_Clear() in the GetItem at LOAD_NAMES ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-02 06:41 Message: Logged In: YES user_id=80475 Made the requested changes, tested, and applied. Will tackle exec and execfile on another day. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-01 15:06 Message: Logged In: YES user_id=4771 Patch reviewed: As eval(expr, mapping) is not accepted but eval(expr, {}, mapping) is, we could have a helpful error message along the line of if (!PyDict_Check(globals)) { PyErr_SetString(PyExc_TypeError, PyMapping_Check(globals) ? "globals must be a real dict; try eval(expr, {}, mapping)" : "globals must be a dict"); } LOAD_NAME: you are doing a speed hack here we will bypass a user-defined __getitem__ on a subclass of dict if the key actually exists in the dictionary. In other words your test with the subclass of dict would fail if the dict aditionally had another real value for the key 'a'. Better use PyDict_CheckExact() in all cases and only call PyDict_GetItem() if it is true, as this is really cheap. Also, no PyErr_Clear() masking arbitrary exceptions please! ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-29 20:38 Message: Logged In: YES user_id=80475 Are you comfortable doing this in two steps. Commit the patch as-is so that eval() works properly and then craft a separate patch to thoroughly implement, test, and document the same thing for exec and execfile()? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-29 10:36 Message: Logged In: YES user_id=4771 Doing the type check in exec and execfile() but not in eval() is not something that seems particularly useful to me. Any program can be written as an expression in Python if you are crazy enough to do that... So it doesn't offer any extra security to be more strict in exec than in eval(). People who really want to do it would have to go through incredible pain just to work around the type check. For the implications, I believe it is sufficient (and necessary) to carefully review all usages of f_locals throughout the code, and document f_locals as no longer necessary a dictionary for those extension writers that would have used this fact. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-29 08:51 Message: Logged In: YES user_id=80475 Okay, a new patch is ready for second review. It is essentially, Armin's patch with the following changes: * leaves the syntax for eval() intact with no automatic globals=locals trick * has the faster approach for LOAD_NAME, incorporating your suggestion for PyDict_CheckExact * omits the code to enable the same liberties for '.exec'. That is beyond the OP's request and well beyond something whose implications I've thought through. Am not opposed to it, but would like it to be left for a separate patch with thorough unittests. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-27 18:08 Message: Logged In: YES user_id=80475 Nix, that last comment. Have examples that call setitem(). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-27 17:36 Message: Logged In: YES user_id=80475 Changed to PyDict_CheckExact(). Are you sure about having to change the sets and dels. I've tried several things at the interactive prompt and can't get it to fail: >>> [locals() for i in (2,3)] Do you have any examples (in part, so I can use them as test cases)? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-27 11:33 Message: Logged In: YES user_id=4771 eval() can set items in the locals, e.g. by using list comprehension. Moreover the ability to exec in custom dicts would be extremely useful too, e.g. to catch definitions while they appear. If you really want to avoid any performance impact, using PyDict_CheckExact() in all critical parts looks good (do not use PyDict_Check(), it's both slower and not what we want because it prevents subclasses of dicts to override __xxxitem__). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-27 08:37 Message: Logged In: YES user_id=80475 Okay, the patch is ready for second review. Attaching the revision with unittests. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-27 07:50 Message: Logged In: YES user_id=80475 Attaching my minimal version of the patch. It runs the attached demo without exception and does not measurably show on any of my timings. The approach is to restrict the generalization to eval() instead of exec(). Since eval() can't set values in the locals dict, no changes are needed to the setitem and delitem calls. Instead of using PyObject_GetItem() directly, I do a regular lookup and fallback to the generalizaiton if necessary -- this is why the normal case doesn't get slowed down (the cost is a PyDict_Check which uses values already in cache, and a branch predicatable comparison).. While the demo script runs, and the test_suite passes, it is slightly too simple and doesn't yet handle eval('dir()', globals(), M()) where M is a non-dict mapping. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-23 16:59 Message: Logged In: YES user_id=80475 The quick patch works fine. Do change the PyArg_ParseTuple() into the faster PyArg_UnpackTuple(). Does this patch show any changes to pystone or other key metrics? Would the PyDict_GetItem trick have better performance? My guess is that it would. +1 on using PyMapping_Check() for checking the locals argument to eval(). That is as good as you can get without actually running it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-22 21:07 Message: Logged In: YES user_id=4771 Quick patch attached. I didn't try to use the PyDict_GetItem trick described, but just systematically use PyObject_GetItem/SetItem/DelItem when working with f_locals. This might confuse some extension modules that expect PyEval_GetLocals() to return a dict object. The eval trick is now: eval(code, nondict) --> eval(code, globals(), nondict). Besides eval() I removed the relevant typecheck from execfile() and the exec statement. Any other place I am missing? We might want to still somehow check the type of the locals, to avoid strange errors caused by e.g. eval("a", "b"). PyMapping_Check() is the obvious candidate, but it looks like a hack. More testing is needed. test_descrtut.py line 84 now succeeds, unexpectedly, which is interpreted as a test failure. Needs some docs, too. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-12 07:27 Message: Logged In: YES user_id=80475 Armin, can you whip-up a quick patch so that we can explore the implications of your suggestion. Ideally, I would like to see something like this go in for Py2.4. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-22 16:53 Message: Logged In: YES user_id=80475 +1 Amrin's idea provides most of the needed functionality with zero performance impact. Also, using a local dictionary for the application variables is likely to be just exactly what a programmer would want to do. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-05-19 18:21 Message: Logged In: YES user_id=4771 With minimal work and performance impact, we could allow frame->f_locals to be something else than a real dictionary. It looks like it would be easily possible as long as we don't touch the time-critical frame->f_globals. Code compiled by eval() always uses LOAD_NAME and STORE_NAME, which is anyway allowed to be a bit slower than LOAD_FAST or LOAD_GLOBAL. Note that PyDict_GetItem() & co., as called by LOAD/STORE_NAME, do a PyDict_Check() anyway. We could just replace it with PyDict_CheckExact() and if it fails fall back to calling the appropriate ob_type->tp_as_mapping method. This would turn some of the PyDict_Xxx() API into a general mapping API, half-way between its current dict-only usage and the fully abstract PyObject_Xxx() API. This is maybe a bit strange from the user's point of view, because eval("expr", mydict) still wouldn't work: only eval("expr", {}, mydict) would. which does which does Now, there is no way I can think of that code compiled by eval() could contain LOAD_GLOBAL or STORE_GLOBAL. The only way to tell the difference between eval("expr", mydict) and eval("expr", {}, mydict) appears to be by calling globals() or somehow inspecting the frame directly. Therefore it might be acceptable to redefine the two-argument eval(expr, dict) to be equivalent not to eval(expr, dict, dict) but eval(expr, {}, dict). This hack might be useful enough even if it won't work with the exec statement. ---------------------------------------------------------------------- Comment By: Bluebird (pfremy) Date: 2004-03-03 09:40 Message: Logged In: YES user_id=233844 I have exactly the same need as the original poster. The only difference in my case is that I inhreted a dictionnary. I want to use the eval() function as a simple expression evaluator. I have the follwing dictionnary: d['a']='1' d['b']='2' d['c']='a+b' I want the following results: d[a] -> 1 d[b] -> 2 d[c] -> 3 To do that, I was planning to use the eval() function and overloading the __getitem__ of the global or local dictionnary: class MyDict( dict ) : def __getitem__( self, key ): print "__getitem__", key val = dict.__getitem__( self, key ) print "val = '%s'" % val return eval( val , self ) But it does not work: d[a]: __getitem__ a val = '1' -> 1 d[b]: __getitem__ b val = '2' -> 2 d[c]: __getitem__ c val = 'e+1' ERROR Traceback (most recent call last): File "test_parse_jaycos_config.py", line 83, in testMyDict self.assertEquals( d['c'], 2 ) File "parse_config_file.py", line 10, in __getitem__ return eval( val , self ) File "", line 0, in ? TypeError: cannot concatenate 'str' and 'int' objects d['c'] did fetch the 'a+1' value, which was passed to eval. However, eval() tried to evaluate the expression using the content of the dictionnary instead of using __getitem__. So it fetched the string '1' for 'a' instead of the value 1, so the result is not suitable for the addition. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-01-12 22:01 Message: Logged In: YES user_id=99874 Hmm... I like this! Of course, I am wary of adding *yet another* special double- underscore function to satisfy a single special purpose, but this would satisfy all of *my* needs, and without any performance impact for lookups that are FOUND. Lookups that are NOT found would have a slight performance degrade (I know better than to speculate about the size of the effect without measuring it). I'm not really sure what percentage of dict lookups succeed. At any rate, what are these "other contexts" you mention in which a __keyerror__ would "also be useful"? Because if we can find other places where it is useful, that significantly improves the usefulness. OTOH, if the tests can be done ONLY for eval (I don't really think that's possible), then I'm certain no one cares about the performance of eval. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2004-01-12 19:38 Message: Logged In: YES user_id=292741 This may be a compromise solution, which could also be useful in other contexts: What if the object passed is derived from dict - presumably that doesn't help because the point is to do low-level calls to the actual dict's lookup functions. Now, suppose we modify the basic dict type, so that before throwing a KeyError, it checks to see if it is really a derived object with a method __keyerror__, and if so, calls that and returns its result (or lets it throw)? Now you can make objects that look like dicts, and act like them at the low level, but can automatically populate themselves when non-existent keys are requested. Of course, __keyerror__('x') does not have to make an 'x' entry in the dict; it could make no change, or add several entries, depending on the desired semantics regarding future lookups. It could be set up so that every lookup fails and is forwarded by __keyerror__ to the __getitem__ of another object, for instance. The cost of this to the 'normal' dict lookup is that the need to do PyDict_CheckExact() each time a lookup fails. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2003-12-16 15:37 Message: Logged In: YES user_id=99874 I'll just add my voice as somebody who would find this to be "darn handy" if it could ever done without noticably impacting the speed of python code that DOESN'T use eval(). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-09-23 04:18 Message: Added to PEP 42. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-09-22 19:42 Message: Changed Group to Feature Request. Should be added to PEP 42 (I'll do that if nobody beats me to it). CPython requires a genuine dict now for speed. I believe JPython allows any mapping object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=215126&group_id=5470 From noreply at sourceforge.net Tue Aug 1 10:40:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 01:40:53 -0700 Subject: [ python-Bugs-1506951 ] pydoc fails on package in ZIP archive Message-ID: Bugs item #1506951, was opened at 2006-06-15 22:07 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506951&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Christopher Dunn (christopherdunn) Assigned to: Nobody/Anonymous (nobody) Summary: pydoc fails on package in ZIP archive Initial Comment: I have Foo/__init__.py and Foo/bar.py in a ZIP archive, test.zip, which is in the PYTHONPATH. pydoc works on Foo.bar, but fails on package Foo. % pydoc Foo Traceback (most recent call last): File "~/bin/pydoc", line 5, in ? pydoc.cli() File "../python-2.4/lib/python2.4/pydoc.py", line 2228, in cli help.help(arg) File "../python-2.4/lib/python2.4/pydoc.py", line 1682, in help elif request: doc(request, 'Help on %s:') File "../python-2.4/lib/python2.4/pydoc.py", line 1468, in doc pager(title % desc + '\n\n' + text.document(object, name)) File "../python-2.4/lib/python2.4/pydoc.py", line 296, in document if inspect.ismodule(object): return self.docmodule(*args) File "../python-2.4/lib/python2.4/pydoc.py", line 1053, in docmodule for file in os.listdir(object.__path__[0]): OSError: [Errno 20] Not a directory: 'test.zip/Foo' ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-01 08:40 Message: Logged In: YES user_id=849994 Agreed. Closing as Fixed. ---------------------------------------------------------------------- Comment By: Žiga Seilnacht (zseil) Date: 2006-07-31 23:49 Message: Logged In: YES user_id=1326842 This is fixed in the 2.5 release. The details of the fix are quite involved, so it is unlikely that it will be backported. See revision 45510 for details: http://mail.python.org/pipermail/python-checkins/2006-April/051452.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506951&group_id=5470 From noreply at sourceforge.net Tue Aug 1 12:49:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 03:49:17 -0700 Subject: [ python-Bugs-215126 ] Over restricted type checking on eval() function Message-ID: Bugs item #215126, was opened at 2000-09-22 19:36 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=215126&group_id=5470 Please note that this 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: Feature Request Status: Closed Resolution: None Priority: 6 Submitted By: Nobody/Anonymous (nobody) Assigned to: Armin Rigo (arigo) Summary: Over restricted type checking on eval() function Initial Comment: The built-in function eval() takes a string argument and a dictionary. The second argument should allow any instance which defines __getitem__ as opposed to just dictionaries. The following example creates a type error: eval, argument 2: expected dictionary, instance found class SpreadSheet: _cells = {} def __setitem__( self, key, formula ): self._cells[key] = formula def __getitem__( self, key ): return eval( self._cells[key], self ) ss = SpreadSheet() ss['a1'] = '5' ss['a2'] = 'a1*5' ss['a2'] ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-08-01 10:49 Message: Logged In: YES user_id=4771 I don't see any missing PyErr_Clear() in LOAD_NAME, but I may be overseeing it. Can you be more specific? Where and why? ---------------------------------------------------------------------- Comment By: Anand Aiyer (aaiyer) Date: 2006-08-01 06:20 Message: Logged In: YES user_id=1554342 There is a missing PyErr_Clear() in the GetItem at LOAD_NAMES ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-07-02 06:41 Message: Logged In: YES user_id=80475 Made the requested changes, tested, and applied. Will tackle exec and execfile on another day. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-07-01 15:06 Message: Logged In: YES user_id=4771 Patch reviewed: As eval(expr, mapping) is not accepted but eval(expr, {}, mapping) is, we could have a helpful error message along the line of if (!PyDict_Check(globals)) { PyErr_SetString(PyExc_TypeError, PyMapping_Check(globals) ? "globals must be a real dict; try eval(expr, {}, mapping)" : "globals must be a dict"); } LOAD_NAME: you are doing a speed hack here we will bypass a user-defined __getitem__ on a subclass of dict if the key actually exists in the dictionary. In other words your test with the subclass of dict would fail if the dict aditionally had another real value for the key 'a'. Better use PyDict_CheckExact() in all cases and only call PyDict_GetItem() if it is true, as this is really cheap. Also, no PyErr_Clear() masking arbitrary exceptions please! ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-29 20:38 Message: Logged In: YES user_id=80475 Are you comfortable doing this in two steps. Commit the patch as-is so that eval() works properly and then craft a separate patch to thoroughly implement, test, and document the same thing for exec and execfile()? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-29 10:36 Message: Logged In: YES user_id=4771 Doing the type check in exec and execfile() but not in eval() is not something that seems particularly useful to me. Any program can be written as an expression in Python if you are crazy enough to do that... So it doesn't offer any extra security to be more strict in exec than in eval(). People who really want to do it would have to go through incredible pain just to work around the type check. For the implications, I believe it is sufficient (and necessary) to carefully review all usages of f_locals throughout the code, and document f_locals as no longer necessary a dictionary for those extension writers that would have used this fact. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-29 08:51 Message: Logged In: YES user_id=80475 Okay, a new patch is ready for second review. It is essentially, Armin's patch with the following changes: * leaves the syntax for eval() intact with no automatic globals=locals trick * has the faster approach for LOAD_NAME, incorporating your suggestion for PyDict_CheckExact * omits the code to enable the same liberties for '.exec'. That is beyond the OP's request and well beyond something whose implications I've thought through. Am not opposed to it, but would like it to be left for a separate patch with thorough unittests. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-27 18:08 Message: Logged In: YES user_id=80475 Nix, that last comment. Have examples that call setitem(). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-27 17:36 Message: Logged In: YES user_id=80475 Changed to PyDict_CheckExact(). Are you sure about having to change the sets and dels. I've tried several things at the interactive prompt and can't get it to fail: >>> [locals() for i in (2,3)] Do you have any examples (in part, so I can use them as test cases)? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-27 11:33 Message: Logged In: YES user_id=4771 eval() can set items in the locals, e.g. by using list comprehension. Moreover the ability to exec in custom dicts would be extremely useful too, e.g. to catch definitions while they appear. If you really want to avoid any performance impact, using PyDict_CheckExact() in all critical parts looks good (do not use PyDict_Check(), it's both slower and not what we want because it prevents subclasses of dicts to override __xxxitem__). ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-27 08:37 Message: Logged In: YES user_id=80475 Okay, the patch is ready for second review. Attaching the revision with unittests. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-27 07:50 Message: Logged In: YES user_id=80475 Attaching my minimal version of the patch. It runs the attached demo without exception and does not measurably show on any of my timings. The approach is to restrict the generalization to eval() instead of exec(). Since eval() can't set values in the locals dict, no changes are needed to the setitem and delitem calls. Instead of using PyObject_GetItem() directly, I do a regular lookup and fallback to the generalizaiton if necessary -- this is why the normal case doesn't get slowed down (the cost is a PyDict_Check which uses values already in cache, and a branch predicatable comparison).. While the demo script runs, and the test_suite passes, it is slightly too simple and doesn't yet handle eval('dir()', globals(), M()) where M is a non-dict mapping. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-23 16:59 Message: Logged In: YES user_id=80475 The quick patch works fine. Do change the PyArg_ParseTuple() into the faster PyArg_UnpackTuple(). Does this patch show any changes to pystone or other key metrics? Would the PyDict_GetItem trick have better performance? My guess is that it would. +1 on using PyMapping_Check() for checking the locals argument to eval(). That is as good as you can get without actually running it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-06-22 21:07 Message: Logged In: YES user_id=4771 Quick patch attached. I didn't try to use the PyDict_GetItem trick described, but just systematically use PyObject_GetItem/SetItem/DelItem when working with f_locals. This might confuse some extension modules that expect PyEval_GetLocals() to return a dict object. The eval trick is now: eval(code, nondict) --> eval(code, globals(), nondict). Besides eval() I removed the relevant typecheck from execfile() and the exec statement. Any other place I am missing? We might want to still somehow check the type of the locals, to avoid strange errors caused by e.g. eval("a", "b"). PyMapping_Check() is the obvious candidate, but it looks like a hack. More testing is needed. test_descrtut.py line 84 now succeeds, unexpectedly, which is interpreted as a test failure. Needs some docs, too. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-06-12 07:27 Message: Logged In: YES user_id=80475 Armin, can you whip-up a quick patch so that we can explore the implications of your suggestion. Ideally, I would like to see something like this go in for Py2.4. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2004-05-22 16:53 Message: Logged In: YES user_id=80475 +1 Amrin's idea provides most of the needed functionality with zero performance impact. Also, using a local dictionary for the application variables is likely to be just exactly what a programmer would want to do. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2004-05-19 18:21 Message: Logged In: YES user_id=4771 With minimal work and performance impact, we could allow frame->f_locals to be something else than a real dictionary. It looks like it would be easily possible as long as we don't touch the time-critical frame->f_globals. Code compiled by eval() always uses LOAD_NAME and STORE_NAME, which is anyway allowed to be a bit slower than LOAD_FAST or LOAD_GLOBAL. Note that PyDict_GetItem() & co., as called by LOAD/STORE_NAME, do a PyDict_Check() anyway. We could just replace it with PyDict_CheckExact() and if it fails fall back to calling the appropriate ob_type->tp_as_mapping method. This would turn some of the PyDict_Xxx() API into a general mapping API, half-way between its current dict-only usage and the fully abstract PyObject_Xxx() API. This is maybe a bit strange from the user's point of view, because eval("expr", mydict) still wouldn't work: only eval("expr", {}, mydict) would. which does which does Now, there is no way I can think of that code compiled by eval() could contain LOAD_GLOBAL or STORE_GLOBAL. The only way to tell the difference between eval("expr", mydict) and eval("expr", {}, mydict) appears to be by calling globals() or somehow inspecting the frame directly. Therefore it might be acceptable to redefine the two-argument eval(expr, dict) to be equivalent not to eval(expr, dict, dict) but eval(expr, {}, dict). This hack might be useful enough even if it won't work with the exec statement. ---------------------------------------------------------------------- Comment By: Bluebird (pfremy) Date: 2004-03-03 09:40 Message: Logged In: YES user_id=233844 I have exactly the same need as the original poster. The only difference in my case is that I inhreted a dictionnary. I want to use the eval() function as a simple expression evaluator. I have the follwing dictionnary: d['a']='1' d['b']='2' d['c']='a+b' I want the following results: d[a] -> 1 d[b] -> 2 d[c] -> 3 To do that, I was planning to use the eval() function and overloading the __getitem__ of the global or local dictionnary: class MyDict( dict ) : def __getitem__( self, key ): print "__getitem__", key val = dict.__getitem__( self, key ) print "val = '%s'" % val return eval( val , self ) But it does not work: d[a]: __getitem__ a val = '1' -> 1 d[b]: __getitem__ b val = '2' -> 2 d[c]: __getitem__ c val = 'e+1' ERROR Traceback (most recent call last): File "test_parse_jaycos_config.py", line 83, in testMyDict self.assertEquals( d['c'], 2 ) File "parse_config_file.py", line 10, in __getitem__ return eval( val , self ) File "", line 0, in ? TypeError: cannot concatenate 'str' and 'int' objects d['c'] did fetch the 'a+1' value, which was passed to eval. However, eval() tried to evaluate the expression using the content of the dictionnary instead of using __getitem__. So it fetched the string '1' for 'a' instead of the value 1, so the result is not suitable for the addition. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2004-01-12 22:01 Message: Logged In: YES user_id=99874 Hmm... I like this! Of course, I am wary of adding *yet another* special double- underscore function to satisfy a single special purpose, but this would satisfy all of *my* needs, and without any performance impact for lookups that are FOUND. Lookups that are NOT found would have a slight performance degrade (I know better than to speculate about the size of the effect without measuring it). I'm not really sure what percentage of dict lookups succeed. At any rate, what are these "other contexts" you mention in which a __keyerror__ would "also be useful"? Because if we can find other places where it is useful, that significantly improves the usefulness. OTOH, if the tests can be done ONLY for eval (I don't really think that's possible), then I'm certain no one cares about the performance of eval. ---------------------------------------------------------------------- Comment By: Gregory Smith (gregsmith) Date: 2004-01-12 19:38 Message: Logged In: YES user_id=292741 This may be a compromise solution, which could also be useful in other contexts: What if the object passed is derived from dict - presumably that doesn't help because the point is to do low-level calls to the actual dict's lookup functions. Now, suppose we modify the basic dict type, so that before throwing a KeyError, it checks to see if it is really a derived object with a method __keyerror__, and if so, calls that and returns its result (or lets it throw)? Now you can make objects that look like dicts, and act like them at the low level, but can automatically populate themselves when non-existent keys are requested. Of course, __keyerror__('x') does not have to make an 'x' entry in the dict; it could make no change, or add several entries, depending on the desired semantics regarding future lookups. It could be set up so that every lookup fails and is forwarded by __keyerror__ to the __getitem__ of another object, for instance. The cost of this to the 'normal' dict lookup is that the need to do PyDict_CheckExact() each time a lookup fails. ---------------------------------------------------------------------- Comment By: Michael Chermside (mcherm) Date: 2003-12-16 15:37 Message: Logged In: YES user_id=99874 I'll just add my voice as somebody who would find this to be "darn handy" if it could ever done without noticably impacting the speed of python code that DOESN'T use eval(). ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-09-23 04:18 Message: Added to PEP 42. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2000-09-22 19:42 Message: Changed Group to Feature Request. Should be added to PEP 42 (I'll do that if nobody beats me to it). CPython requires a genuine dict now for speed. I believe JPython allows any mapping object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=215126&group_id=5470 From noreply at sourceforge.net Tue Aug 1 16:52:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 07:52:26 -0700 Subject: [ python-Bugs-1532483 ] the csv module writes files that Excel sees as SYLK files Message-ID: Bugs item #1532483, was opened at 2006-08-01 14: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=1532483&group_id=5470 Please note that this 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: Vincent Povirk (madewokherd) Assigned to: Nobody/Anonymous (nobody) Summary: the csv module writes files that Excel sees as SYLK files Initial Comment: I'm using python version 2.4.3 Apparently, when Excel 2003 reads a file, it looks for the identifying string "ID" at the beginning of the file. If it finds this string, it assumes it's reading an SYLK file (see http://netghost.narod.ru/gff/graphics/summary/micsylk.htm for some information on SYLK). The csv module will generate a file that starts with ID if the first field it writes starts with ID and does not need to be quoted. When Excel tries to open the file, the following message pops up: "Excel has detected that 'test.csv' is a SYLK file, but cannot load it. Either the file has errors or it is not a SYLK file format. Click OK to try to open the file in a different format." Excel can read the file after clicking OK. Excel actually has the same problem with CSV files it has written. Even so, when using the 'excel' dialect, csv should write files that Excel can open without any problems. It could do this by quoting the first field in the file if it begins with "ID". Unfortunately, csv's Dialect class does not make this possible. I'm currently working around it by using QUOTE_NONNUMERIC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532483&group_id=5470 From noreply at sourceforge.net Tue Aug 1 18:16:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 09:16:52 -0700 Subject: [ python-Bugs-1530448 ] ctypes build fails on Solaris 10 Message-ID: Bugs item #1530448, was opened at 2006-07-28 10:04 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2006-08-01 11:16 Message: Logged In: YES user_id=44345 Thomas> Skip, do you have *any* idea what might be Thomas> wrong, or could you even come up with a patch? Skip> I've no idea so far. I'll try to find some time Skip> to take a look at it later today. Thomas, Sorry for the delay. I think I have it figured out and it was fairly straightforward. Looking at the files in order on the _ctypes.so link line we see that the definition of ffi_closure_SYSV_inner is defined before it's referenced: for obj in build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ; do echo $obj; nm -p $obj | egrep ffi_closure_SYSV_inner; done build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o 0000000456 T ffi_closure_SYSV_inner build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o 0000000000 U ffi_closure_SYSV_inner Since we're linking from object files, it's a one-pass link algorithm. At the time ffo.o is examined, sysv.o hasn't been seen. Consequently, ffi_closure_SYSV_inner is not yet known and its definition isn't picked up from ffi.o. I couldn't quickly figure out where the link command is generated, but I'm sure you'll know where it resides. Either swap ffi.o and sysv.o on the link line, or add ffi.o a second time to resolve the new reference. Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-31 05:54 Message: Logged In: YES user_id=11105 Skip, do you have *any* idea what might be wrong, or could you even come up with a patch? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-07-28 17:03 Message: Logged In: YES user_id=44345 Yeah, you'd definitely need -fPIC on any brand of Solaris. That test might be changed to plat = get_platform() if plat in (... buncha platforms ...) or "solaris" in plat: os.environ["CFLAGS"] = "-fPIC" That doesn't seem to be what's happening in this case though. I rm'd the .o files in .../Modules/_ctypes and tried again. The compile commands *do* have -fPIC on them. I don't think it's required on the link line. S ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-28 11:19 Message: Logged In: YES user_id=11105 Skip, This looks *somewhat* like the problems reported in bugs 1529269 and 1528620 (although they have a sparc, and you seem to have x86 solaris). Hm, in the standalone ctypes setup script, I find this code snippet: if get_platform() in ["solaris-2.9-sun4u", "linux-x86_64"]: os.environ["CFLAGS"] = "-fPIC" Can it be that -fPIC must be used, but is not specified? It is also funny that the solaris buildbot does NOT seem to have a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 From noreply at sourceforge.net Tue Aug 1 18:22:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 09:22:58 -0700 Subject: [ python-Bugs-1532483 ] the csv module writes files that Excel sees as SYLK files Message-ID: Bugs item #1532483, was opened at 2006-08-01 09:52 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532483&group_id=5470 Please note that this 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: Vincent Povirk (madewokherd) >Assigned to: Skip Montanaro (montanaro) Summary: the csv module writes files that Excel sees as SYLK files Initial Comment: I'm using python version 2.4.3 Apparently, when Excel 2003 reads a file, it looks for the identifying string "ID" at the beginning of the file. If it finds this string, it assumes it's reading an SYLK file (see http://netghost.narod.ru/gff/graphics/summary/micsylk.htm for some information on SYLK). The csv module will generate a file that starts with ID if the first field it writes starts with ID and does not need to be quoted. When Excel tries to open the file, the following message pops up: "Excel has detected that 'test.csv' is a SYLK file, but cannot load it. Either the file has errors or it is not a SYLK file format. Click OK to try to open the file in a different format." Excel can read the file after clicking OK. Excel actually has the same problem with CSV files it has written. Even so, when using the 'excel' dialect, csv should write files that Excel can open without any problems. It could do this by quoting the first field in the file if it begins with "ID". Unfortunately, csv's Dialect class does not make this possible. I'm currently working around it by using QUOTE_NONNUMERIC. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2006-08-01 11:22 Message: Logged In: YES user_id=44345 Seems like a shortcoming in Excel 2003 to me, not a problem with the csv module. Still, if you can suggest a change that won't break many other uses of the csv module's output, I'll consider it. Have you tried the same test with a later version of Excel? Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532483&group_id=5470 From noreply at sourceforge.net Tue Aug 1 20:01:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 11:01:44 -0700 Subject: [ python-Bugs-1532483 ] the csv module writes files that Excel sees as SYLK files Message-ID: Bugs item #1532483, was opened at 2006-08-01 14:52 Message generated for change (Comment added) made by madewokherd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532483&group_id=5470 Please note that this 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: Vincent Povirk (madewokherd) Assigned to: Skip Montanaro (montanaro) Summary: the csv module writes files that Excel sees as SYLK files Initial Comment: I'm using python version 2.4.3 Apparently, when Excel 2003 reads a file, it looks for the identifying string "ID" at the beginning of the file. If it finds this string, it assumes it's reading an SYLK file (see http://netghost.narod.ru/gff/graphics/summary/micsylk.htm for some information on SYLK). The csv module will generate a file that starts with ID if the first field it writes starts with ID and does not need to be quoted. When Excel tries to open the file, the following message pops up: "Excel has detected that 'test.csv' is a SYLK file, but cannot load it. Either the file has errors or it is not a SYLK file format. Click OK to try to open the file in a different format." Excel can read the file after clicking OK. Excel actually has the same problem with CSV files it has written. Even so, when using the 'excel' dialect, csv should write files that Excel can open without any problems. It could do this by quoting the first field in the file if it begins with "ID". Unfortunately, csv's Dialect class does not make this possible. I'm currently working around it by using QUOTE_NONNUMERIC. ---------------------------------------------------------------------- >Comment By: Vincent Povirk (madewokherd) Date: 2006-08-01 18:01 Message: Logged In: YES user_id=553355 Thanks for your response. Yes, it's definitely a bug in Excel 2003 (as it also complains about files it saved). I do not have a later version of Excel to test. Microsoft has a page about this issue that seems to say 2003 is the last version with that problem: http://support.microsoft.com/kb/323626/ Their solution is worse than the problem, I'd be interested in seeing how a later version behaves. I know that if the first cell is quoted, Excel will open it without complaining. I think the best solution would be to quote the first cell if it starts with ID by introducing a new QUOTE_ constant. I don't know how that part of the code works (I'm too lazy to read things that aren't written in python); maybe it's more reasonable to quote any field starting with ID. I don't know of any other uses that would break, but I'm not in touch with many csv users. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-01 16:22 Message: Logged In: YES user_id=44345 Seems like a shortcoming in Excel 2003 to me, not a problem with the csv module. Still, if you can suggest a change that won't break many other uses of the csv module's output, I'll consider it. Have you tried the same test with a later version of Excel? Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532483&group_id=5470 From noreply at sourceforge.net Tue Aug 1 21:04:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 12:04:12 -0700 Subject: [ python-Bugs-1525343 ] Webserver TypeError: expected read buffer, NoneType found Message-ID: Bugs item #1525343, was opened at 2006-07-19 10:53 Message generated for change (Comment added) made by whit537 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525343&group_id=5470 Please note that this 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: jbet (jbeisert) Assigned to: Nobody/Anonymous (nobody) Summary: Webserver TypeError: expected read buffer, NoneType found Initial Comment: When I'm using the python webserver I got the following message for every access by my client. Soryy, I have no experience in Python, so I cannot help. This is only a report. HTTPdaemon_v1.0.0 listening on port 8001 ---------------------------------------- Exception happened during processing of request from ('192.168.1.9', 33917) Traceback (most recent call last): File "/home/jb/bin/lib/python2.5/SocketServer.py", line 463, in process_request_thread self.finish_request(request, client_address) File "/home/jb/bin/lib/python2.5/SocketServer.py", line 254, in finish_request self.RequestHandlerClass(request, client_address, self) File "/home/jb/bin/lib/python2.5/SocketServer.py", line 521, in __init__ self.handle() File "/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line 316, in handle self.handle_one_request() File "/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line 310, in handle_one_request method() File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 53, in do_GET self.handle_request() File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 56, in handle_request httpreq = HSHTTPRequest(self) File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 254, in __init__ keep_blank_values = True File "/home/jb/bin/lib/python2.5/cgi.py", line 462, in __init__ fp = StringIO(qs) TypeError: expected read buffer, NoneType found ---------------------------------------- ---------------------------------------- Exception happened during processing of request from ('192.168.1.9', 33918) Traceback (most recent call last): File "/home/jb/bin/lib/python2.5/SocketServer.py", line 463, in process_request_thread self.finish_request(request, client_address) File "/home/jb/bin/lib/python2.5/SocketServer.py", line 254, in finish_request self.RequestHandlerClass(request, client_address, self) File "/home/jb/bin/lib/python2.5/SocketServer.py", line 521, in __init__ self.handle() File "/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line 316, in handle self.handle_one_request() File "/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line 310, in handle_one_request method() File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 53, in do_GET self.handle_request() File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 56, in handle_request httpreq = HSHTTPRequest(self) File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 254, in __init__ keep_blank_values = True File "/home/jb/bin/lib/python2.5/cgi.py", line 462, in __init__ fp = StringIO(qs) TypeError: expected read buffer, NoneType found ---------------------------------------- ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-08-01 15:04 Message: Logged In: YES user_id=340931 Thanks for the report. Can I ask how you came to use the as-yet-unreleased Python 2.5 if you have no experience with Python? It looks like you are having this problem with Myghty. Does that require Python 2.5? FWIW, this looks to me like a problem with Myghty's use of the cgi module, not a problem with Python itself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525343&group_id=5470 From noreply at sourceforge.net Tue Aug 1 22:02:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 13:02:29 -0700 Subject: [ python-Bugs-1530448 ] ctypes build fails on Solaris 10 Message-ID: Bugs item #1530448, was opened at 2006-07-28 17:04 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-08-01 22:02 Message: Logged In: YES user_id=11105 I didn't know there are any systems that depend on the order of object files on the linker command line any more ;-). IIUC, the objects list is derived by distutils from the sources list, so the attached patch (for Modules/_ctypes/libffi/fficonfig.py.in) *could* do the trick. Please make sure that fficonfig.py is recreated (by doing make clean before building or whatever). Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-01 18:16 Message: Logged In: YES user_id=44345 Thomas> Skip, do you have *any* idea what might be Thomas> wrong, or could you even come up with a patch? Skip> I've no idea so far. I'll try to find some time Skip> to take a look at it later today. Thomas, Sorry for the delay. I think I have it figured out and it was fairly straightforward. Looking at the files in order on the _ctypes.so link line we see that the definition of ffi_closure_SYSV_inner is defined before it's referenced: for obj in build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ; do echo $obj; nm -p $obj | egrep ffi_closure_SYSV_inner; done build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o 0000000456 T ffi_closure_SYSV_inner build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o 0000000000 U ffi_closure_SYSV_inner Since we're linking from object files, it's a one-pass link algorithm. At the time ffo.o is examined, sysv.o hasn't been seen. Consequently, ffi_closure_SYSV_inner is not yet known and its definition isn't picked up from ffi.o. I couldn't quickly figure out where the link command is generated, but I'm sure you'll know where it resides. Either swap ffi.o and sysv.o on the link line, or add ffi.o a second time to resolve the new reference. Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-31 12:54 Message: Logged In: YES user_id=11105 Skip, do you have *any* idea what might be wrong, or could you even come up with a patch? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-07-29 00:03 Message: Logged In: YES user_id=44345 Yeah, you'd definitely need -fPIC on any brand of Solaris. That test might be changed to plat = get_platform() if plat in (... buncha platforms ...) or "solaris" in plat: os.environ["CFLAGS"] = "-fPIC" That doesn't seem to be what's happening in this case though. I rm'd the .o files in .../Modules/_ctypes and tried again. The compile commands *do* have -fPIC on them. I don't think it's required on the link line. S ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-28 18:19 Message: Logged In: YES user_id=11105 Skip, This looks *somewhat* like the problems reported in bugs 1529269 and 1528620 (although they have a sparc, and you seem to have x86 solaris). Hm, in the standalone ctypes setup script, I find this code snippet: if get_platform() in ["solaris-2.9-sun4u", "linux-x86_64"]: os.environ["CFLAGS"] = "-fPIC" Can it be that -fPIC must be used, but is not specified? It is also funny that the solaris buildbot does NOT seem to have a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 From noreply at sourceforge.net Tue Aug 1 23:02:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 14:02:25 -0700 Subject: [ python-Bugs-1527397 ] PythonLauncher uses incorrect working directory Message-ID: Bugs item #1527397, was opened at 2006-07-23 19:29 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527397&group_id=5470 Please note that this 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.5 >Status: Pending >Resolution: Fixed Priority: 7 Submitted By: Bob Ippolito (etrepum) >Assigned to: Ronald Oussoren (ronaldoussoren) Summary: PythonLauncher uses incorrect working directory Initial Comment: PythonLauncher, the application used to launch .py files by double-click, does not launch with the correct working directory. This means that any script that depends on data files will not work via PythonLauncher. Users expect the working directory to be that of the launched script, like on other platforms, but PythonLauncher launches with a working directory of $HOME. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-01 23:02 Message: Logged In: YES user_id=580910 Fixed in revision 51028. Please confirm. The same revision also fixes a problem where PythonLauncher failed to launch scripts if the name contains quotes (e.g. "Ronald's Script.py"). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-23 20:50 Message: Logged In: YES user_id=580910 I agree that the current behaviour is not what users expect and should be considered a bug. I'd like to get the attached patch into 2.5, it changes the CWD to the directory containing the script and should be perfectly save. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527397&group_id=5470 From noreply at sourceforge.net Tue Aug 1 23:11:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 14:11:10 -0700 Subject: [ python-Bugs-835790 ] MacPython builds with DESTROOT need fixup Message-ID: Bugs item #835790, was opened at 2003-11-04 16:43 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835790&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: MacPython builds with DESTROOT need fixup Initial Comment: Currently building MacPython with DESTROOT causes the #! lines in the applet boot scripts to be incorrect (they include DESTROOT, but shouldn't). At the moment we fix this up later, but it would be better if they were built correctly in the first place. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-01 23:11 Message: Logged In: YES user_id=580910 I don't think this is an issue anymore, but maybe just accidently. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835790&group_id=5470 From noreply at sourceforge.net Tue Aug 1 23:13:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 14:13:44 -0700 Subject: [ python-Bugs-764975 ] Installing 2.3b2 on to non-system disk fails Message-ID: Bugs item #764975, was opened at 2003-07-03 00:45 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764975&group_id=5470 Please note that this 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.3 >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: Rob Managan (managan) Assigned to: Jack Jansen (jackjansen) Summary: Installing 2.3b2 on to non-system disk fails Initial Comment: When installing 2.3b2 I was allowed to choose a non-system disk. It did create an Applications folder and installed into it. Parts of the framework were installed correctly (based onmod dates) but it did not work properly. After installing on the system disk the IDE worked fine but the package manager did not except from within the IDE. I suspect double clicking on the Package Manager was trying to use an older version of python, possibly Apple's. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-01 23:13 Message: Logged In: YES user_id=580910 The Python2.5 installer won't allow installation to non-system disks and that seems to work fine. The same is true of the universal installer for 2.4.3. Installing on other disks won't work because the framework and the python and pythonw executables contain hardcoded paths. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-23 12:55 Message: Logged In: YES user_id=45365 For some reason setting rootDiskOnly causes strange error messages to appear in the installer, and you have to switch disks back and forth to make installation possible. And people with only one disk don't even have this option. The problem is probably that the packages created by our buildpkg.py module aren't fully adhering to the (unwritten) standard. For now the workaround is to allow non-system-disk installs, but warn people in the welcome message that this doesn't work. For the future we should either fix buildpkg or replace it with a module that uses OSA to talk to the Apple Package Maker tool. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=764975&group_id=5470 From noreply at sourceforge.net Tue Aug 1 23:14:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 14:14:54 -0700 Subject: [ python-Bugs-1087737 ] Mac: make frameworkinstall skips docs, scripts Message-ID: Bugs item #1087737, was opened at 2004-12-19 01:09 Message generated for change (Settings changed) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087737&group_id=5470 Please note that this 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: Open >Resolution: Wont Fix Priority: 5 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Mac: make frameworkinstall skips docs, scripts Initial Comment: "make frameworkinstall" for a framework build of Python installs a symlink to the interpreter in /usr/local, but it doesn't do the same for the man page, scripts and maybe other auxiliary files. Either it needs to install these, or it needs to be documented that they aren't installed, preferably with an option to install them with an extra make. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-06-25 23:27 Message: Logged In: YES user_id=580910 Current wisdom seems to be that it's better to add the directories inside the framework to relevant paths (PATH and MANPATH) instead of adding symlinks in /usr/local. The binary installer will install a symlink to the embedded documentation in / Developer/Documentation. IMHO this can be closed. BTW. 'make frameworkinstall' is deprecated as well, just use 'make install'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1087737&group_id=5470 From noreply at sourceforge.net Tue Aug 1 23:20:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 14:20:35 -0700 Subject: [ python-Bugs-1532726 ] incorrect behaviour of PyUnicode_EncodeMBCS? Message-ID: Bugs item #1532726, was opened at 2006-08-01 23: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=1532726&group_id=5470 Please note that this 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: Jan-Willem (jwnmulder) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect behaviour of PyUnicode_EncodeMBCS? Initial Comment: Using python 2.4.3 This behaviour is not reproducable on a window or linux machine. I found the bug when trying to find a problem on python 2.4.3 ported to the xbox. running the next two commands test_string = 'encode me' print repr(test_string.encode('mbcs')) results on windows in : 'encode me' and on the xbox : 'encode me\\x00' The problem is that 'PyUnicode_EncodeMBCS' returns an PyStringObject that contains the data 'encode me' but with an object size of 10. string_repr(test_string) assumes the string contains a 0 character and encodes it as '\\x00' looking at the function 'PyUnicode_EncodeMBCS(const Py_UNICODE *p, int size, const char *errors)' there are basicly two functions { mbcssize = WideCharToMultiByte(CP_ACP, 0, p, size, NULL, 0, NULL, NULL); repr = PyString_FromStringAndSize(NULL, mbcssize); } WideCharToMultiByte returns the nummer of bytes needed for the buffer, because of the string termination this functions returns 10. PyString_FromStringAndSize assumes its second argument to be the number of needed characters, not bytes. So an easy fix would be to change repr = PyString_FromStringAndSize(NULL, mbcssize); in repr = PyString_FromStringAndSize(NULL, mbcssize - 1); Just checked the 2.4.3 svn trunk and it contains the same bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532726&group_id=5470 From noreply at sourceforge.net Tue Aug 1 23:30:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 14:30:23 -0700 Subject: [ python-Bugs-1532726 ] incorrect behaviour of PyUnicode_EncodeMBCS? Message-ID: Bugs item #1532726, was opened at 2006-08-01 23:20 Message generated for change (Comment added) made by jwnmulder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532726&group_id=5470 Please note that this 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: Jan-Willem (jwnmulder) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect behaviour of PyUnicode_EncodeMBCS? Initial Comment: Using python 2.4.3 This behaviour is not reproducable on a window or linux machine. I found the bug when trying to find a problem on python 2.4.3 ported to the xbox. running the next two commands test_string = 'encode me' print repr(test_string.encode('mbcs')) results on windows in : 'encode me' and on the xbox : 'encode me\\x00' The problem is that 'PyUnicode_EncodeMBCS' returns an PyStringObject that contains the data 'encode me' but with an object size of 10. string_repr(test_string) assumes the string contains a 0 character and encodes it as '\\x00' looking at the function 'PyUnicode_EncodeMBCS(const Py_UNICODE *p, int size, const char *errors)' there are basicly two functions { mbcssize = WideCharToMultiByte(CP_ACP, 0, p, size, NULL, 0, NULL, NULL); repr = PyString_FromStringAndSize(NULL, mbcssize); } WideCharToMultiByte returns the nummer of bytes needed for the buffer, because of the string termination this functions returns 10. PyString_FromStringAndSize assumes its second argument to be the number of needed characters, not bytes. So an easy fix would be to change repr = PyString_FromStringAndSize(NULL, mbcssize); in repr = PyString_FromStringAndSize(NULL, mbcssize - 1); Just checked the 2.4.3 svn trunk and it contains the same bug. ---------------------------------------------------------------------- >Comment By: Jan-Willem (jwnmulder) Date: 2006-08-01 23:30 Message: Logged In: YES user_id=770969 related to patch 1455898 ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532726&group_id=5470 From noreply at sourceforge.net Wed Aug 2 07:13:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 22:13:19 -0700 Subject: [ python-Bugs-1532920 ] os.path.isfile('CON:') does not behave as documented Message-ID: Bugs item #1532920, was opened at 2006-08-02 15:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532920&group_id=5470 Please note that this 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: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.isfile('CON:') does not behave as documented Initial Comment: In Windows, os.path.isfile() returns True for device filenames such as 'CON:', 'NUL:', 'AUX:', 'PRN:', and 'C:\\Program Files\\con.mp3'. The documentation for os.path.isfile() says that it returns True only for regular files, so it should return False for the above examples (or else the documentation should be amended). In Linux, os.path.isfile('/dev/null') returns False as expected. This problem occurs because the ?stat? function in Microsoft?s C library behaves differently than in *nix. Quoting from Microsoft's documentation for stat: ?st_mode: ... the _S_IFREG bit is set if path specifies an ordinary file or a device? http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt__stat.2c_._wstat.2c_._stati64.2c_._wstati64.asp A similar problem exists with stat.S_ISREG(os.stat('CON:').st_mode) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532920&group_id=5470 From noreply at sourceforge.net Wed Aug 2 07:31:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 22:31:33 -0700 Subject: [ python-Bugs-1532726 ] incorrect behaviour of PyUnicode_EncodeMBCS? Message-ID: Bugs item #1532726, was opened at 2006-08-02 06:20 Message generated for change (Comment added) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532726&group_id=5470 Please note that this 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: Jan-Willem (jwnmulder) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect behaviour of PyUnicode_EncodeMBCS? Initial Comment: Using python 2.4.3 This behaviour is not reproducable on a window or linux machine. I found the bug when trying to find a problem on python 2.4.3 ported to the xbox. running the next two commands test_string = 'encode me' print repr(test_string.encode('mbcs')) results on windows in : 'encode me' and on the xbox : 'encode me\\x00' The problem is that 'PyUnicode_EncodeMBCS' returns an PyStringObject that contains the data 'encode me' but with an object size of 10. string_repr(test_string) assumes the string contains a 0 character and encodes it as '\\x00' looking at the function 'PyUnicode_EncodeMBCS(const Py_UNICODE *p, int size, const char *errors)' there are basicly two functions { mbcssize = WideCharToMultiByte(CP_ACP, 0, p, size, NULL, 0, NULL, NULL); repr = PyString_FromStringAndSize(NULL, mbcssize); } WideCharToMultiByte returns the nummer of bytes needed for the buffer, because of the string termination this functions returns 10. PyString_FromStringAndSize assumes its second argument to be the number of needed characters, not bytes. So an easy fix would be to change repr = PyString_FromStringAndSize(NULL, mbcssize); in repr = PyString_FromStringAndSize(NULL, mbcssize - 1); Just checked the 2.4.3 svn trunk and it contains the same bug. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-08-02 14:31 Message: Logged In: YES user_id=1200846 I think this is not related to that patch. On my win2000sp4, teminating null character is not passed to PyUnicode_EncodeMBCS. ////////////////////////////////////////////// // patch for debug (release24-maint branch) Index: Objects/unicodeobject.c =================================================================== --- Objects/unicodeobject.c (revision 51033) +++ Objects/unicodeobject.c (working copy) @@ -2782,6 +2782,20 @@ char *s; DWORD mbcssize; +{ /* debug */ + + int i; + + printf("------------> %d\n", size); + + for (i = 0; i < size; ++i) { + printf("%d ", (int)p[i]); + } + + printf("\n"); + +} /* debug */ + /* If there are no characters, bail now! */ if (size==0) return PyString_FromString(""); ////////////////////////////////// // a.py test_string = 'encode me' print repr(test_string.encode('mbcs')) ////////////////////////////////// // result R:\>py a.py ------------> 9 101 110 99 111 100 101 32 109 101 'encode me' [7660 refs] And I tried this. #include #include #include void count(LPCWSTR w, int size) { char *buf; int i; const int ret = ::WideCharToMultiByte( CP_ACP, 0, w, size, NULL, 0, NULL, NULL ); if (ret == 0) { printf("error\n"); } else { printf("%d\n", ret); } buf = (char*)malloc(ret); ::WideCharToMultiByte( CP_ACP, 0, w, size, buf, ret, NULL, NULL ); for (i = 0; i < ret; ++i) { printf("%d ", (int)buf[i]); } printf("\n"); free(buf); } int main() { count(L"encode me", 9); count(L"encode me", 10); /* include null charater */ } /* 9 101 110 99 111 100 101 32 109 101 10 101 110 99 111 100 101 32 109 101 0 */ As stated in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_2bj9.asp , WideCharToMultiByte never output null character if source string doesn't contain null character. So I think usage of WideCharToMultiByte is correct. I don't know why, but probably some behavior difference should exist between win2000 and xbox. (ie: xbox calls PyUnicode_EncodeMBCS with size 10 ... or WideCharToMultiByte on xbox outputs null character even if source string doesn't contain it?) Can you try above C code and debug patch on xbox? ---------------------------------------------------------------------- Comment By: Jan-Willem (jwnmulder) Date: 2006-08-02 06:30 Message: Logged In: YES user_id=770969 related to patch 1455898 ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532726&group_id=5470 From noreply at sourceforge.net Wed Aug 2 08:47:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Aug 2006 23:47:55 -0700 Subject: [ python-Bugs-926423 ] socket timeouts + Ctrl-C don't play nice Message-ID: Bugs item #926423, was opened at 2004-03-30 19:48 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926423&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library >Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David M. Cooke (dmcooke) >Assigned to: Neal Norwitz (nnorwitz) Summary: socket timeouts + Ctrl-C don't play nice Initial Comment: As reported by Koen Vossen in c.l.py, when a timeout is set on a socket, a try...except block around a socket.recv (or socket.recvfrom) won't properly catch a keyboard interrupt (by Ctrl-C). I've attached example code that shows this. Run it and press Ctrl-C before the socket times out. This is for Python 2.3 under Linux. I believe the problem boils down to this sequence of events inside of the socketmodule.c::sock_recv function (and similiar for sock_recvfrom): 1) internal_select is called, which calls select, which waits for a timeout. A SIGINT is received (and caught by the default handler). The select returns with errno set to EINTR. internal_select returns with timeout==1 2) without checking errno, recv() is called. Since there is actually no data, it returns an error, with errno set to EAGAIN. 3) the default socket error handler is called, which calls PyErr_SetFromErrno(). Since errno != EINTR (it's now EAGAIN), a socket_error exception is thrown. 4) the innermost try..except block is triggered. 5) next loop around in eval_frame, notices that SIGINT was caught, and so KeyboardInterrupt is raised, exiting innermost try..except clause 6) KeyboardInterrupt is caught by the outermost try..except block. I was going to make a patch, but I couldn't figure out the best way to fix this in general :-( There are likely similiar problems with everywhere internal_select is used. The quick fix is to check errno before calling recv() ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-01 23:47 Message: Logged In: YES user_id=33168 Committed revision 51039. (2.5) ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-15 03:38 Message: Logged In: YES user_id=129426 I've submitted a patch, it's at 1102879 Please have a close look at it. ---------------------------------------------------------------------- Comment By: David M. Cooke (dmcooke) Date: 2005-01-13 15:28 Message: Logged In: YES user_id=65069 Looks like my assertion that timeout==1 is wrong :-). Otherwise, the analysis is correct: recv is called when select() retuned EINTR. I think your approach is the way to go. Since the return value of internal_select is no longer a boolean for a timeout, maybe in the expressions "timeout = internal_select(...)", "timeout" should be renamed to something more generic (possibly 'selectresult')? ---------------------------------------------------------------------- Comment By: Irmen de Jong (irmen) Date: 2005-01-13 14:59 Message: Logged In: YES user_id=129426 (confirmed on Python 2.4 and HEAD) But: your analysis is not correct: internal_select doesn't return with timeout==1 when a SIGINT occurs, instead it returns 0, because it doesn't check for an error condition that select() may return. So I hacked around a bit and changed internal_select to return -1 when the select() system call returns -1, and then also added the following in sock_recv: if(errno) { Py_DECREF(buf); return PyErr_SetFromErrno(socket_error); } Which seems to make the example script that is attached to this bug report run as expected. As you say, I also think that this check must be added at all locations where internal_select is called. What do you say? I can make a patch if this is okay. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926423&group_id=5470 From noreply at sourceforge.net Wed Aug 2 14:28:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 05:28:40 -0700 Subject: [ python-Bugs-1470212 ] mailbox.PortableUnixMailbox fails to parse 'From ' in body Message-ID: Bugs item #1470212, was opened at 2006-04-13 23:35 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470212&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Lars Kellogg-Stedman (larsks) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox.PortableUnixMailbox fails to parse 'From ' in body Initial Comment: I have a Unix mailbox file that contains the following text in the body of a message: ---[ cut here ]--- EFCO also offers casements with integral blinds. See:=20 http://www.efcocorp.com/public/earm/products/default.asp?j=3D1&P=3D43&L=3D= 1=20 >From that page, select select "Features and Benefits" from under the heading "Product Overview"=20 ---[ cut here ]--- mailbox.PortableUnixMailbox erroneously interprets the "From" at the beginning of the line as the beginning of a new message. Since 'From ' is only a valid header at the beginning of a message, perhaps the module could look at the following line and see if it looks like an RFC2822 header before accepting 'From ' as a message delimiter. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-02 08:28 Message: Logged In: YES user_id=11375 See the comment in mailbox.py in the UnixMailbox class, too. UnixMailbox uses a stricter regex to look for from lines, but this proves too strict in practice so PortableUnixMailbox is much less strict. mbox format isn't very good, and we're just stuck with this behaviour. Closing this bug as "won't fix". ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2006-04-14 04:30 Message: Logged In: YES user_id=1185570 Use rfc822.py in lieu of mailbox to first parse the message into an rfc822.Message... then pass it to the Mailbox.PortableUnixMailbox constructor. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1470212&group_id=5470 From noreply at sourceforge.net Wed Aug 2 14:48:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 05:48:30 -0700 Subject: [ python-Bugs-1531662 ] Build fails on MacOSX with missing symbol Message-ID: Bugs item #1531662, was opened at 2006-07-31 12:58 Message generated for change (Comment added) made by gdm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531662&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 >Status: Closed Resolution: None Priority: 7 Submitted By: gideon may (gdm) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Build fails on MacOSX with missing symbol Initial Comment: When compiling the latest svn version on MacOS, the build fails with the following error in libpython2.5.a: ld: Undefined symbols: _init_types libtool: internal link edit command failed When I add Modules/_typesmodule.c to Modules/Setup.dist everything is hunky-dory, but am not sure if this is the correct place since python seems to compile ok on Linux without the addition ---------------------------------------------------------------------- >Comment By: gideon may (gdm) Date: 2006-08-02 14:48 Message: Logged In: YES user_id=117359 The error was completely mine, you were right about junk files still laying around. Have been able to create a clean build, both with and without frameworks ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-31 21:58 Message: Logged In: YES user_id=580910 I cannot reproduce this with the current head (svnversion says 51008). Did you do a clean build? Maybe some junk from a previous build caused problems. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-31 21:43 Message: Logged In: YES user_id=580910 Did you build a unix or framework install? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531662&group_id=5470 From noreply at sourceforge.net Wed Aug 2 15:00:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 06:00:21 -0700 Subject: [ python-Bugs-1533105 ] NetBSD build with --with-pydebug causes SIGSEGV Message-ID: Bugs item #1533105, was opened at 2006-08-02 13: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=1533105&group_id=5470 Please note that this 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: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: NetBSD build with --with-pydebug causes SIGSEGV Initial Comment: The testInfiniteRecursion test in Lib/test/test_exceptions.py causes Python to segfault if it has been compiled on NetBSD with --with-pydebug. This is due to the fact that the default stack size on NetBSD is 2MB and Python tries to allocate memory for debugging information on the stack. The documentation (README under 'Setting the optimization/debugging options'?) should be updated to state that if you want to run the test suite with debugging enabled in the interpreter, you are advised to increase the stack size, probably to 4096. This issue is also in release24-maint. Matt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533105&group_id=5470 From noreply at sourceforge.net Wed Aug 2 15:08:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 06:08:55 -0700 Subject: [ python-Bugs-1530448 ] ctypes build fails on Solaris 10 Message-ID: Bugs item #1530448, was opened at 2006-07-28 10:04 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2006-08-02 08:08 Message: Logged In: YES user_id=44345 I don't understand. I swapped the order of ffi.c and sysv.S in the platforms dict. I confirmed that the order of the .o files on the link line changed so that ffi.o followed sysv.o. I still get the same error. I've also confirmed that ffi.o exports the symbol and that sysv.o references it: % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 U _GLOBAL_OFFSET_TABLE_ 0000000000 f ffi.c 0000000332 T ffi_call 0000000000 U ffi_call_SYSV 0000000000 U ffi_closure_SYSV 0000000456 T ffi_closure_SYSV_inner 0000000000 T ffi_prep_args 0000000252 T ffi_prep_cif_machdep 0000000612 T ffi_prep_closure 0000000000 U memcpy % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000109 n epilogue 0000000000 T ffi_call_SYSV 0000000116 T ffi_closure_SYSV 0000000000 U ffi_closure_SYSV_inner 0000000000 U ffi_prep_args 0000000109 n noretval 0000000071 n retdouble 0000000059 n retfloat 0000000046 n retint 0000000095 n retint64 0000000083 n retlongdouble 0000000109 n retstruct All the object files were compiled with -fPIC. Here's the relevant chunk of make's output: creating build/temp.solaris-2.10-i86pc-2.5/libffi checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for gcc... /opt/app/g++lib6/gcc-3.4/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /opt/app/g++lib6/gcc-3.4/bin/gcc accepts -g... yes checking for /opt/app/g++lib6/gcc-3.4/bin/gcc option to accept ANSI C... none needed checking how to run the C preprocessor... /opt/app/g++lib6/gcc-3.4/bin/gcc -E checking for egrep... egrep checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking sys/mman.h usability... yes checking sys/mman.h presence... yes checking for sys/mman.h... yes checking for mmap... yes checking for sys/mman.h... (cached) yes checking for mmap... (cached) yes checking whether read-only mmap of a plain file works... yes checking whether mmap from /dev/zero works... yes checking for MAP_ANON(YMOUS)... yes checking whether mmap with MAP_ANON(YMOUS) works... yes checking for ANSI C header files... (cached) yes checking for memcpy... yes checking for working alloca.h... yes checking for alloca... yes checking for double... yes checking size of double... 8 checking for long double... yes checking size of long double... 12 checking whether byte ordering is bigendian... no checking whether .eh_frame section should be read-only... no checking for __attribute__((visibility("hidden")))... no configure: creating ./config.status config.status: creating include/ffi.h config.status: creating fficonfig.py config.status: creating fficonfig.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffitarget.h to include/ffitarget.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/include/ffi_common.h to include/ffi_common.h config.status: executing include commands config.status: executing src commands >>> X86_64 ['src/prep_cif.c', 'src/x86/ffi64.c', 'src/x86/unix64.S', 'src/x86/sysv.S', 'src/x86/ffi.c'] building '_ctypes' extension /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c: In function `_CallProc': /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c:917: warning: implicit declaration of function `alloca' /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:177: warning: function declaration isn't a prototype /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:194: warning: function declaration isn't a prototype /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I added a couple prints to fficonfig.py.in to demonstrate the file order and platform name (and to make sure fficonfig.py was being rebuilt). Oddly enough, if I remove both ffi.o and sysv.o from the link line, it links successfully. Is that significant or am I just getting desparate? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-01 15:02 Message: Logged In: YES user_id=11105 I didn't know there are any systems that depend on the order of object files on the linker command line any more ;-). IIUC, the objects list is derived by distutils from the sources list, so the attached patch (for Modules/_ctypes/libffi/fficonfig.py.in) *could* do the trick. Please make sure that fficonfig.py is recreated (by doing make clean before building or whatever). Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-01 11:16 Message: Logged In: YES user_id=44345 Thomas> Skip, do you have *any* idea what might be Thomas> wrong, or could you even come up with a patch? Skip> I've no idea so far. I'll try to find some time Skip> to take a look at it later today. Thomas, Sorry for the delay. I think I have it figured out and it was fairly straightforward. Looking at the files in order on the _ctypes.so link line we see that the definition of ffi_closure_SYSV_inner is defined before it's referenced: for obj in build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ; do echo $obj; nm -p $obj | egrep ffi_closure_SYSV_inner; done build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o 0000000456 T ffi_closure_SYSV_inner build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o 0000000000 U ffi_closure_SYSV_inner Since we're linking from object files, it's a one-pass link algorithm. At the time ffo.o is examined, sysv.o hasn't been seen. Consequently, ffi_closure_SYSV_inner is not yet known and its definition isn't picked up from ffi.o. I couldn't quickly figure out where the link command is generated, but I'm sure you'll know where it resides. Either swap ffi.o and sysv.o on the link line, or add ffi.o a second time to resolve the new reference. Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-31 05:54 Message: Logged In: YES user_id=11105 Skip, do you have *any* idea what might be wrong, or could you even come up with a patch? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-07-28 17:03 Message: Logged In: YES user_id=44345 Yeah, you'd definitely need -fPIC on any brand of Solaris. That test might be changed to plat = get_platform() if plat in (... buncha platforms ...) or "solaris" in plat: os.environ["CFLAGS"] = "-fPIC" That doesn't seem to be what's happening in this case though. I rm'd the .o files in .../Modules/_ctypes and tried again. The compile commands *do* have -fPIC on them. I don't think it's required on the link line. S ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-28 11:19 Message: Logged In: YES user_id=11105 Skip, This looks *somewhat* like the problems reported in bugs 1529269 and 1528620 (although they have a sparc, and you seem to have x86 solaris). Hm, in the standalone ctypes setup script, I find this code snippet: if get_platform() in ["solaris-2.9-sun4u", "linux-x86_64"]: os.environ["CFLAGS"] = "-fPIC" Can it be that -fPIC must be used, but is not specified? It is also funny that the solaris buildbot does NOT seem to have a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 From noreply at sourceforge.net Wed Aug 2 15:20:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 06:20:42 -0700 Subject: [ python-Bugs-1530448 ] ctypes build fails on Solaris 10 Message-ID: Bugs item #1530448, was opened at 2006-07-28 17:04 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-08-02 15:20 Message: Logged In: YES user_id=11105 It seems that the files 'src/x86/ffi.c' and 'src/x86/sysv.S' are not needed for the X86_64 platform in fficonfig.py.in. They *should* compile to nothing, anyway, because their contents is protected by 'ifndef __x86_64__'. Does removing them from fficonfig.py.in change the situation, so that only this remains: 'X86_64': ['src/x86/ffi64.c', 'src/x86/unix64.S'], I can build _ctypes on an unbuntu amd64 system with this change. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-02 15:08 Message: Logged In: YES user_id=44345 I don't understand. I swapped the order of ffi.c and sysv.S in the platforms dict. I confirmed that the order of the .o files on the link line changed so that ffi.o followed sysv.o. I still get the same error. I've also confirmed that ffi.o exports the symbol and that sysv.o references it: % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 U _GLOBAL_OFFSET_TABLE_ 0000000000 f ffi.c 0000000332 T ffi_call 0000000000 U ffi_call_SYSV 0000000000 U ffi_closure_SYSV 0000000456 T ffi_closure_SYSV_inner 0000000000 T ffi_prep_args 0000000252 T ffi_prep_cif_machdep 0000000612 T ffi_prep_closure 0000000000 U memcpy % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000109 n epilogue 0000000000 T ffi_call_SYSV 0000000116 T ffi_closure_SYSV 0000000000 U ffi_closure_SYSV_inner 0000000000 U ffi_prep_args 0000000109 n noretval 0000000071 n retdouble 0000000059 n retfloat 0000000046 n retint 0000000095 n retint64 0000000083 n retlongdouble 0000000109 n retstruct All the object files were compiled with -fPIC. Here's the relevant chunk of make's output: creating build/temp.solaris-2.10-i86pc-2.5/libffi checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for gcc... /opt/app/g++lib6/gcc-3.4/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /opt/app/g++lib6/gcc-3.4/bin/gcc accepts -g... yes checking for /opt/app/g++lib6/gcc-3.4/bin/gcc option to accept ANSI C... none needed checking how to run the C preprocessor... /opt/app/g++lib6/gcc-3.4/bin/gcc -E checking for egrep... egrep checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking sys/mman.h usability... yes checking sys/mman.h presence... yes checking for sys/mman.h... yes checking for mmap... yes checking for sys/mman.h... (cached) yes checking for mmap... (cached) yes checking whether read-only mmap of a plain file works... yes checking whether mmap from /dev/zero works... yes checking for MAP_ANON(YMOUS)... yes checking whether mmap with MAP_ANON(YMOUS) works... yes checking for ANSI C header files... (cached) yes checking for memcpy... yes checking for working alloca.h... yes checking for alloca... yes checking for double... yes checking size of double... 8 checking for long double... yes checking size of long double... 12 checking whether byte ordering is bigendian... no checking whether .eh_frame section should be read-only... no checking for __attribute__((visibility("hidden")))... no configure: creating ./config.status config.status: creating include/ffi.h config.status: creating fficonfig.py config.status: creating fficonfig.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffitarget.h to include/ffitarget.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/include/ffi_common.h to include/ffi_common.h config.status: executing include commands config.status: executing src commands >>> X86_64 ['src/prep_cif.c', 'src/x86/ffi64.c', 'src/x86/unix64.S', 'src/x86/sysv.S', 'src/x86/ffi.c'] building '_ctypes' extension /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c: In function `_CallProc': /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c:917: warning: implicit declaration of function `alloca' /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:177: warning: function declaration isn't a prototype /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:194: warning: function declaration isn't a prototype /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I added a couple prints to fficonfig.py.in to demonstrate the file order and platform name (and to make sure fficonfig.py was being rebuilt). Oddly enough, if I remove both ffi.o and sysv.o from the link line, it links successfully. Is that significant or am I just getting desparate? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-01 22:02 Message: Logged In: YES user_id=11105 I didn't know there are any systems that depend on the order of object files on the linker command line any more ;-). IIUC, the objects list is derived by distutils from the sources list, so the attached patch (for Modules/_ctypes/libffi/fficonfig.py.in) *could* do the trick. Please make sure that fficonfig.py is recreated (by doing make clean before building or whatever). Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-01 18:16 Message: Logged In: YES user_id=44345 Thomas> Skip, do you have *any* idea what might be Thomas> wrong, or could you even come up with a patch? Skip> I've no idea so far. I'll try to find some time Skip> to take a look at it later today. Thomas, Sorry for the delay. I think I have it figured out and it was fairly straightforward. Looking at the files in order on the _ctypes.so link line we see that the definition of ffi_closure_SYSV_inner is defined before it's referenced: for obj in build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ; do echo $obj; nm -p $obj | egrep ffi_closure_SYSV_inner; done build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o 0000000456 T ffi_closure_SYSV_inner build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o 0000000000 U ffi_closure_SYSV_inner Since we're linking from object files, it's a one-pass link algorithm. At the time ffo.o is examined, sysv.o hasn't been seen. Consequently, ffi_closure_SYSV_inner is not yet known and its definition isn't picked up from ffi.o. I couldn't quickly figure out where the link command is generated, but I'm sure you'll know where it resides. Either swap ffi.o and sysv.o on the link line, or add ffi.o a second time to resolve the new reference. Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-31 12:54 Message: Logged In: YES user_id=11105 Skip, do you have *any* idea what might be wrong, or could you even come up with a patch? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-07-29 00:03 Message: Logged In: YES user_id=44345 Yeah, you'd definitely need -fPIC on any brand of Solaris. That test might be changed to plat = get_platform() if plat in (... buncha platforms ...) or "solaris" in plat: os.environ["CFLAGS"] = "-fPIC" That doesn't seem to be what's happening in this case though. I rm'd the .o files in .../Modules/_ctypes and tried again. The compile commands *do* have -fPIC on them. I don't think it's required on the link line. S ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-28 18:19 Message: Logged In: YES user_id=11105 Skip, This looks *somewhat* like the problems reported in bugs 1529269 and 1528620 (although they have a sparc, and you seem to have x86 solaris). Hm, in the standalone ctypes setup script, I find this code snippet: if get_platform() in ["solaris-2.9-sun4u", "linux-x86_64"]: os.environ["CFLAGS"] = "-fPIC" Can it be that -fPIC must be used, but is not specified? It is also funny that the solaris buildbot does NOT seem to have a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 From noreply at sourceforge.net Wed Aug 2 15:28:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 06:28:58 -0700 Subject: [ python-Bugs-1532483 ] the csv module writes files that Excel sees as SYLK files Message-ID: Bugs item #1532483, was opened at 2006-08-01 09:52 Message generated for change (Settings changed) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532483&group_id=5470 Please note that this 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: Pending Resolution: None Priority: 5 Submitted By: Vincent Povirk (madewokherd) Assigned to: Skip Montanaro (montanaro) Summary: the csv module writes files that Excel sees as SYLK files Initial Comment: I'm using python version 2.4.3 Apparently, when Excel 2003 reads a file, it looks for the identifying string "ID" at the beginning of the file. If it finds this string, it assumes it's reading an SYLK file (see http://netghost.narod.ru/gff/graphics/summary/micsylk.htm for some information on SYLK). The csv module will generate a file that starts with ID if the first field it writes starts with ID and does not need to be quoted. When Excel tries to open the file, the following message pops up: "Excel has detected that 'test.csv' is a SYLK file, but cannot load it. Either the file has errors or it is not a SYLK file format. Click OK to try to open the file in a different format." Excel can read the file after clicking OK. Excel actually has the same problem with CSV files it has written. Even so, when using the 'excel' dialect, csv should write files that Excel can open without any problems. It could do this by quoting the first field in the file if it begins with "ID". Unfortunately, csv's Dialect class does not make this possible. I'm currently working around it by using QUOTE_NONNUMERIC. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2006-08-02 08:28 Message: Logged In: YES user_id=44345 Vincent, A simple workaround would be to define a fully quoting dialect: class quoted_excel(csv.excel): quoting=csv.QUOTE_NONNUMERIC # or QUOTE_ALL That would cause your generated CSV files to start with a quote character, e.g.: "ID","FOO" 1,"bar" 2,"bAz" Try that and see if it makes Excel 2003 happy. Skip ---------------------------------------------------------------------- Comment By: Vincent Povirk (madewokherd) Date: 2006-08-01 13:01 Message: Logged In: YES user_id=553355 Thanks for your response. Yes, it's definitely a bug in Excel 2003 (as it also complains about files it saved). I do not have a later version of Excel to test. Microsoft has a page about this issue that seems to say 2003 is the last version with that problem: http://support.microsoft.com/kb/323626/ Their solution is worse than the problem, I'd be interested in seeing how a later version behaves. I know that if the first cell is quoted, Excel will open it without complaining. I think the best solution would be to quote the first cell if it starts with ID by introducing a new QUOTE_ constant. I don't know how that part of the code works (I'm too lazy to read things that aren't written in python); maybe it's more reasonable to quote any field starting with ID. I don't know of any other uses that would break, but I'm not in touch with many csv users. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-01 11:22 Message: Logged In: YES user_id=44345 Seems like a shortcoming in Excel 2003 to me, not a problem with the csv module. Still, if you can suggest a change that won't break many other uses of the csv module's output, I'll consider it. Have you tried the same test with a later version of Excel? Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532483&group_id=5470 From noreply at sourceforge.net Wed Aug 2 16:34:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 07:34:54 -0700 Subject: [ python-Bugs-1533164 ] Installed but not listed *.pyo break bdist_rpm Message-ID: Bugs item #1533164, was opened at 2006-08-02 18:34 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533164&group_id=5470 Please note that this 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: Shmyrev Nick (nshmyrev) Assigned to: Nobody/Anonymous (nobody) Summary: Installed but not listed *.pyo break bdist_rpm Initial Comment: This bug is forwarded from redhat's bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198877 ------------------------------------------- Description of problem: setup.py fails to build rpm. How reproducible: Always Steps to Reproduce: 1. Create dir "foo" with these files: foo.py setup.py setup.py contains: ---- #!/usr/bin/env python from distutils.core import setup setup( name='foo', version='0.1', py_modules=['foo'], ) ---- contents of file foo.py is not important. 2. from the 'foo' directory run python setup.py bdist_rpm Actual results: building of rpm fails with Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/foo-0.1-1-buildroot error: Installed (but unpackaged) file(s) found: /usr/lib/python2.4/site-packages/foo.pyo Expected results: The command above should create a rpm package. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533164&group_id=5470 From noreply at sourceforge.net Wed Aug 2 19:12:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 10:12:48 -0700 Subject: [ python-Bugs-1530959 ] distutils doesn't notice --with-pydebug Message-ID: Bugs item #1530959, was opened at 2006-07-29 13:45 Message generated for change (Comment added) made by collinwinter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530959&group_id=5470 Please note that this 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: Collin Winter (collinwinter) Assigned to: Nobody/Anonymous (nobody) Summary: distutils doesn't notice --with-pydebug Initial Comment: As it stands (as of r50921), building a C extension module first with a debug build of Python (built with --with-pydebug), then with a regular Python build (without --with-pydebug) does not cause distutils to recompile the extension module as it should. This leads to undefined symbol errors at runtime when the module is loaded. The attached patch against Lib/distutils/command/build.py causes distutils.command.build to append '-pydebug' to the platform-specific directory name (e.g., 'linux-i686-2.5') if Python was compiled with --with-pydebug. ---------------------------------------------------------------------- >Comment By: Collin Winter (collinwinter) Date: 2006-08-02 13:12 Message: Logged In: YES user_id=1344176 I've updated the patch to r51046. Also attached is an entry for Misc/NEWS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530959&group_id=5470 From noreply at sourceforge.net Wed Aug 2 19:44:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 10:44:40 -0700 Subject: [ python-Bugs-1532726 ] incorrect behaviour of PyUnicode_EncodeMBCS? Message-ID: Bugs item #1532726, was opened at 2006-08-01 23:20 Message generated for change (Comment added) made by jwnmulder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532726&group_id=5470 Please note that this 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: Jan-Willem (jwnmulder) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect behaviour of PyUnicode_EncodeMBCS? Initial Comment: Using python 2.4.3 This behaviour is not reproducable on a window or linux machine. I found the bug when trying to find a problem on python 2.4.3 ported to the xbox. running the next two commands test_string = 'encode me' print repr(test_string.encode('mbcs')) results on windows in : 'encode me' and on the xbox : 'encode me\\x00' The problem is that 'PyUnicode_EncodeMBCS' returns an PyStringObject that contains the data 'encode me' but with an object size of 10. string_repr(test_string) assumes the string contains a 0 character and encodes it as '\\x00' looking at the function 'PyUnicode_EncodeMBCS(const Py_UNICODE *p, int size, const char *errors)' there are basicly two functions { mbcssize = WideCharToMultiByte(CP_ACP, 0, p, size, NULL, 0, NULL, NULL); repr = PyString_FromStringAndSize(NULL, mbcssize); } WideCharToMultiByte returns the nummer of bytes needed for the buffer, because of the string termination this functions returns 10. PyString_FromStringAndSize assumes its second argument to be the number of needed characters, not bytes. So an easy fix would be to change repr = PyString_FromStringAndSize(NULL, mbcssize); in repr = PyString_FromStringAndSize(NULL, mbcssize - 1); Just checked the 2.4.3 svn trunk and it contains the same bug. ---------------------------------------------------------------------- >Comment By: Jan-Willem (jwnmulder) Date: 2006-08-02 19:44 Message: Logged In: YES user_id=770969 and the result for the xbox 10 101 110 99 111 100 101 32 109 101 0 11 101 110 99 111 100 101 32 109 101 0 0 It seems the xbox calculates an extra character for a '\0' count(L"encode me", -1); results on both platforms in ret = 10 So I think this bug can be closed and clasified as an xbox bug... Not so hard for us to fix, almost all api calls for dlls are emulated in our application, so it is easy enough to put a fix in for us. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-08-02 07:31 Message: Logged In: YES user_id=1200846 I think this is not related to that patch. On my win2000sp4, teminating null character is not passed to PyUnicode_EncodeMBCS. ////////////////////////////////////////////// // patch for debug (release24-maint branch) Index: Objects/unicodeobject.c =================================================================== --- Objects/unicodeobject.c (revision 51033) +++ Objects/unicodeobject.c (working copy) @@ -2782,6 +2782,20 @@ char *s; DWORD mbcssize; +{ /* debug */ + + int i; + + printf("------------> %d\n", size); + + for (i = 0; i < size; ++i) { + printf("%d ", (int)p[i]); + } + + printf("\n"); + +} /* debug */ + /* If there are no characters, bail now! */ if (size==0) return PyString_FromString(""); ////////////////////////////////// // a.py test_string = 'encode me' print repr(test_string.encode('mbcs')) ////////////////////////////////// // result R:\>py a.py ------------> 9 101 110 99 111 100 101 32 109 101 'encode me' [7660 refs] And I tried this. #include #include #include void count(LPCWSTR w, int size) { char *buf; int i; const int ret = ::WideCharToMultiByte( CP_ACP, 0, w, size, NULL, 0, NULL, NULL ); if (ret == 0) { printf("error\n"); } else { printf("%d\n", ret); } buf = (char*)malloc(ret); ::WideCharToMultiByte( CP_ACP, 0, w, size, buf, ret, NULL, NULL ); for (i = 0; i < ret; ++i) { printf("%d ", (int)buf[i]); } printf("\n"); free(buf); } int main() { count(L"encode me", 9); count(L"encode me", 10); /* include null charater */ } /* 9 101 110 99 111 100 101 32 109 101 10 101 110 99 111 100 101 32 109 101 0 */ As stated in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_2bj9.asp , WideCharToMultiByte never output null character if source string doesn't contain null character. So I think usage of WideCharToMultiByte is correct. I don't know why, but probably some behavior difference should exist between win2000 and xbox. (ie: xbox calls PyUnicode_EncodeMBCS with size 10 ... or WideCharToMultiByte on xbox outputs null character even if source string doesn't contain it?) Can you try above C code and debug patch on xbox? ---------------------------------------------------------------------- Comment By: Jan-Willem (jwnmulder) Date: 2006-08-01 23:30 Message: Logged In: YES user_id=770969 related to patch 1455898 ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532726&group_id=5470 From noreply at sourceforge.net Wed Aug 2 23:52:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 14:52:40 -0700 Subject: [ python-Bugs-1524938 ] PEP MemoryError with a lot of available memory gc not called Message-ID: Bugs item #1524938, was opened at 2006-07-18 22:46 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470 Please note that this 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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Mark Matusevich (markmat) Assigned to: Nobody/Anonymous (nobody) Summary: PEP MemoryError with a lot of available memory gc not called Initial Comment: Also the gc behavior is consistent with the documentation, I beleave it is wrong. I think, that Gc should be called automatically before any memory allocation is raised. Example 1: for i in range(700): a = [range(5000000)] a.append(a) print i This example will crash on any any PC with less then 20Gb RAM. On my PC (Windows 2000, 256Mb) it crashes at i==7. Also, this example can be fixed by addition of a call to gc.collect() in the loop, in real cases it may be unreasonable. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-02 17:52 Message: Logged In: YES user_id=764593 Doing it everywhere would be a lot of painful changes. Adding the "oops, failed, call gc and try again" to to PyMem_* (currently PyMem_Malloc, PyMem_Realloc, PyMem_New, and PyMem_Resize, but Brett may be changing that) is far more reasonable. Whether it is safe to call gc from there is a different question. ---------------------------------------------------------------------- Comment By: Mark Matusevich (markmat) Date: 2006-07-23 16:19 Message: Logged In: YES user_id=1337765 Sorry, my last comment was to illume (I am slow typer :( ) ---------------------------------------------------------------------- Comment By: Mark Matusevich (markmat) Date: 2006-07-23 16:11 Message: Logged In: YES user_id=1337765 This is exectly what I meant. For my recollection, this is the policy in Java GC. I never had to handle MemoryError in Java, because I knew, that I really do not have any more memory. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-07-23 16:00 Message: Logged In: YES user_id=21627 This is very difficult to implement. The best way might be to introduce yet another allocation function, one that invokes gc before failing, and call that function in all interesting places (of which there are many). Contributions are welcome and should probably start with a PEP first. ---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2006-07-19 19:20 Message: Logged In: YES user_id=2042 Perhaps better than checking before every memory allocation, would be to check once a memory error happens in an allocation. That way there is only the gc hit once there is low memory. So... res = malloc(...); if(!res) { gc.collect(); } res = malloc(...); if(!res) { raise memory error. } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470 From noreply at sourceforge.net Thu Aug 3 00:04:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 15:04:12 -0700 Subject: [ python-Bugs-1525343 ] Webserver TypeError: expected read buffer, NoneType found Message-ID: Bugs item #1525343, was opened at 2006-07-19 10:53 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525343&group_id=5470 Please note that this 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: jbet (jbeisert) Assigned to: Nobody/Anonymous (nobody) Summary: Webserver TypeError: expected read buffer, NoneType found Initial Comment: When I'm using the python webserver I got the following message for every access by my client. Soryy, I have no experience in Python, so I cannot help. This is only a report. HTTPdaemon_v1.0.0 listening on port 8001 ---------------------------------------- Exception happened during processing of request from ('192.168.1.9', 33917) Traceback (most recent call last): File "/home/jb/bin/lib/python2.5/SocketServer.py", line 463, in process_request_thread self.finish_request(request, client_address) File "/home/jb/bin/lib/python2.5/SocketServer.py", line 254, in finish_request self.RequestHandlerClass(request, client_address, self) File "/home/jb/bin/lib/python2.5/SocketServer.py", line 521, in __init__ self.handle() File "/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line 316, in handle self.handle_one_request() File "/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line 310, in handle_one_request method() File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 53, in do_GET self.handle_request() File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 56, in handle_request httpreq = HSHTTPRequest(self) File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 254, in __init__ keep_blank_values = True File "/home/jb/bin/lib/python2.5/cgi.py", line 462, in __init__ fp = StringIO(qs) TypeError: expected read buffer, NoneType found ---------------------------------------- ---------------------------------------- Exception happened during processing of request from ('192.168.1.9', 33918) Traceback (most recent call last): File "/home/jb/bin/lib/python2.5/SocketServer.py", line 463, in process_request_thread self.finish_request(request, client_address) File "/home/jb/bin/lib/python2.5/SocketServer.py", line 254, in finish_request self.RequestHandlerClass(request, client_address, self) File "/home/jb/bin/lib/python2.5/SocketServer.py", line 521, in __init__ self.handle() File "/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line 316, in handle self.handle_one_request() File "/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line 310, in handle_one_request method() File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 53, in do_GET self.handle_request() File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 56, in handle_request httpreq = HSHTTPRequest(self) File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 254, in __init__ keep_blank_values = True File "/home/jb/bin/lib/python2.5/cgi.py", line 462, in __init__ fp = StringIO(qs) TypeError: expected read buffer, NoneType found ---------------------------------------- ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-02 18:04 Message: Logged In: YES user_id=764593 I suspect that changing >>> fp = StringIO(qs) to >>> fp = StringIO(qs or "") would fix the problem. If so, this is arguably a bug in myghty. qs was already set to "" unless sys.argv[1] or environ['QUERY_STRING']had a value. Neither of these should ever be None. (They should be either a string, or not found.) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-08-01 15:04 Message: Logged In: YES user_id=340931 Thanks for the report. Can I ask how you came to use the as-yet-unreleased Python 2.5 if you have no experience with Python? It looks like you are having this problem with Myghty. Does that require Python 2.5? FWIW, this looks to me like a problem with Myghty's use of the cgi module, not a problem with Python itself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525343&group_id=5470 From noreply at sourceforge.net Thu Aug 3 00:11:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 15:11:49 -0700 Subject: [ python-Bugs-1533481 ] CTypes _as_parameter_ not working as documented Message-ID: Bugs item #1533481, was opened at 2006-08-02 16:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Shane Holloway (shane_holloway) Assigned to: Nobody/Anonymous (nobody) Summary: CTypes _as_parameter_ not working as documented Initial Comment: Reference: http://docs.python.org/dev/lib/ctypes-calling-functions- with-own-custom-data-types.html According to this document, I should be able to use my own objects with ctypes, provided I have an _as_parameter_ attribute set on my object. However, this does not work properly when the foreign function's argtypes have been set. This is because the _as_parameter_ access is not done until after the argument types are checked. Attached is a patch that adds _as_parameter_ checking to the types provided by _ctypes.c so that the feature works as documented for both typed and untyped foreign functions. (Patch is against: svn rev 50859) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533481&group_id=5470 From noreply at sourceforge.net Thu Aug 3 00:13:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 15:13:43 -0700 Subject: [ python-Bugs-1533481 ] CTypes _as_parameter_ not working as documented Message-ID: Bugs item #1533481, was opened at 2006-08-02 16:11 Message generated for change (Comment added) made by shane_holloway You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Shane Holloway (shane_holloway) Assigned to: Nobody/Anonymous (nobody) Summary: CTypes _as_parameter_ not working as documented Initial Comment: Reference: http://docs.python.org/dev/lib/ctypes-calling-functions- with-own-custom-data-types.html According to this document, I should be able to use my own objects with ctypes, provided I have an _as_parameter_ attribute set on my object. However, this does not work properly when the foreign function's argtypes have been set. This is because the _as_parameter_ access is not done until after the argument types are checked. Attached is a patch that adds _as_parameter_ checking to the types provided by _ctypes.c so that the feature works as documented for both typed and untyped foreign functions. (Patch is against: svn rev 50859) ---------------------------------------------------------------------- >Comment By: Shane Holloway (shane_holloway) Date: 2006-08-02 16:13 Message: Logged In: YES user_id=283742 A related patch is http://python.org/sf/1532975 that simplifies the implementation of _as_parameter_ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533481&group_id=5470 From noreply at sourceforge.net Thu Aug 3 00:13:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 15:13:58 -0700 Subject: [ python-Bugs-1531405 ] format_exception raises if str(exception) raises Message-ID: Bugs item #1531405, was opened at 2006-07-30 17:06 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470 Please note that this 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: 9 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: format_exception raises if str(exception) raises Initial Comment: Previously format_exception_only used _some_str() to find the string representation of an exception. In current trunk at HEAD that code has been factored into _format_final_exc_line and changed in two ways: it now calls str(exception) twice instead of once and in one of those cases, it calls str() directly rather than through _some_str, which does exception handling. The end result of this is that application-level code which uses the traceback module to format exceptions which previously could not raise exceptions now can raise exceptions. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-02 18:13 Message: Logged In: YES user_id=764593 Jp -- is this the same issue as 1515163 (patch 1515343)? If so, it should be cleared up in the traceback.py from head. Could you doublecheck? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470 From noreply at sourceforge.net Thu Aug 3 00:18:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 15:18:58 -0700 Subject: [ python-Bugs-1533486 ] long -> Py_ssize_t (C/API 1.2.1) Message-ID: Bugs item #1533486, was opened at 2006-08-02 18: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=1533486&group_id=5470 Please note that this 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: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: long -> Py_ssize_t (C/API 1.2.1) Initial Comment: In the C/API reference manual section 1.2.1, should "assuming sizeof(long) >= sizeof(char*)" change long to Py_ssize_t? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533486&group_id=5470 From noreply at sourceforge.net Thu Aug 3 00:21:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 15:21:33 -0700 Subject: [ python-Bugs-1533491 ] C/API sec 10 is clipped Message-ID: Bugs item #1533491, was opened at 2006-08-02 18:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533491&group_id=5470 Please note that this 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: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: C/API sec 10 is clipped Initial Comment: As of 2.5b2, section 10 of the C/API reference manual seems clipped. Sections 10.4, 10.5, and 10.6 are at best placeholders, and 10.8 isn't even that. (It looks like they could be either on their own as sections, or inlined to an earlier section, and both places are TBD, but the section doesn't make this as obvious.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533491&group_id=5470 From noreply at sourceforge.net Thu Aug 3 00:26:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 15:26:42 -0700 Subject: [ python-Bugs-1533493 ] Tools/modulator does not exist (ext 1.4) Message-ID: Bugs item #1533493, was opened at 2006-08-02 18:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533493&group_id=5470 Please note that this 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: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: Tools/modulator does not exist (ext 1.4) Initial Comment: As of 2.5b2, Extending and Embedding section 1.4 says that modulator is included with the windows installer. It wasn't. The text suggested likely alternate locations of Tools/ modulator/ or Tools/Scripts/Modul*, but these were also missing. (I see Tools/modulator/ in the svn repository; it just wasn't installed on windows.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533493&group_id=5470 From noreply at sourceforge.net Thu Aug 3 00:32:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 15:32:14 -0700 Subject: [ python-Bugs-960860 ] botched html for index subheadings Message-ID: Bugs item #960860, was opened at 2004-05-26 10:17 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960860&group_id=5470 Please note that this 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: Jim Jewett (jimjjewett) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: botched html for index subheadings Initial Comment: In the index, if a topic has subtopics, it should be listed as """
topic
subtopic1
subtopic2
""" In some cases (such as the reference manual entries for module, or object(continued)), it is correct. In other cases (such as the entries for name, or the first column of object), the "
...
" wrapper is left out, so that the subentries appear to be normal entries that just happen to be out of alphabetical order. ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2006-08-02 18:32 Message: Logged In: YES user_id=764593 It was fixed as of 2.5b2 (possibly earlier). Thank you. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-29 16:15 Message: Logged In: YES user_id=3066 This appears to be fine in the 2.4.3 and development versions of the documentation. If I'm missing something, please be specific about what you think is wrong. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960860&group_id=5470 From noreply at sourceforge.net Thu Aug 3 00:32:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 15:32:39 -0700 Subject: [ python-Bugs-960860 ] botched html for index subheadings Message-ID: Bugs item #960860, was opened at 2004-05-26 10:17 Message generated for change (Settings changed) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960860&group_id=5470 Please note that this 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: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: botched html for index subheadings Initial Comment: In the index, if a topic has subtopics, it should be listed as """
topic
subtopic1
subtopic2
""" In some cases (such as the reference manual entries for module, or object(continued)), it is correct. In other cases (such as the entries for name, or the first column of object), the "
...
" wrapper is left out, so that the subentries appear to be normal entries that just happen to be out of alphabetical order. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-02 18:32 Message: Logged In: YES user_id=764593 It was fixed as of 2.5b2 (possibly earlier). Thank you. ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-07-29 16:15 Message: Logged In: YES user_id=3066 This appears to be fine in the 2.4.3 and development versions of the documentation. If I'm missing something, please be specific about what you think is wrong. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=960860&group_id=5470 From noreply at sourceforge.net Thu Aug 3 00:55:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 15:55:55 -0700 Subject: [ python-Bugs-1531405 ] format_exception raises if str(exception) raises Message-ID: Bugs item #1531405, was opened at 2006-07-30 17:06 Message generated for change (Comment added) made by kuran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470 Please note that this 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: 9 Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: format_exception raises if str(exception) raises Initial Comment: Previously format_exception_only used _some_str() to find the string representation of an exception. In current trunk at HEAD that code has been factored into _format_final_exc_line and changed in two ways: it now calls str(exception) twice instead of once and in one of those cases, it calls str() directly rather than through _some_str, which does exception handling. The end result of this is that application-level code which uses the traceback module to format exceptions which previously could not raise exceptions now can raise exceptions. ---------------------------------------------------------------------- >Comment By: Jp Calderone (kuran) Date: 2006-08-02 18:55 Message: Logged In: YES user_id=366566 I don't think those are related. To clarify, this is the case I am talking about: Python 2.5b2 (trunk:50989, Jul 30 2006, 15:42:25) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X: ... def __str__(self): 1/0 ... >>> import traceback >>> traceback.format_exception_only(X, X()) Traceback (most recent call last): File "", line 1, in File "/home/exarkun/Projects/python/trunk/Lib/traceback.py", line 179, in format_exception_only return [_format_final_exc_line(stype, value)] File "/home/exarkun/Projects/python/trunk/Lib/traceback.py", line 205, in _format_final_exc_line if value is None or not str(value): File "", line 2, in __str__ ZeroDivisionError: integer division or modulo by zero >>> Compare this to the Python 2.4 output: Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X: ... def __str__(self): 1/0 ... >>> import traceback >>> traceback.format_exception_only(X, X()) ['X: \n'] >>> ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-02 18:13 Message: Logged In: YES user_id=764593 Jp -- is this the same issue as 1515163 (patch 1515343)? If so, it should be cleared up in the traceback.py from head. Could you doublecheck? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470 From noreply at sourceforge.net Thu Aug 3 03:46:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 18:46:20 -0700 Subject: [ python-Bugs-1193190 ] MACOSX_DEPLOYMENT_TARGET checked incorrectly Message-ID: Bugs item #1193190, was opened at 2005-04-30 20:15 Message generated for change (Settings changed) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193190&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.5 >Status: Closed Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Bob Ippolito (etrepum) Summary: MACOSX_DEPLOYMENT_TARGET checked incorrectly Initial Comment: MACOSX_DEPLOYMENT_TARGET should be checked to be >= the configure time value (or not set). Currently, it checks for equality. For example, this is necessary in order to use a Python built for Mac OS X 10.3 but build an extension with features specific to Mac OS X 10.4. Backport candidate to 2.4, patches attached. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-04-17 10:44 Message: Logged In: YES user_id=580910 Applied as revision 45490 on the trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1193190&group_id=5470 From noreply at sourceforge.net Thu Aug 3 04:10:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 19:10:37 -0700 Subject: [ python-Bugs-1530559 ] struct.pack raises TypeError where it used to convert Message-ID: Bugs item #1530559, was opened at 2006-07-28 14:07 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470 Please note that this 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: 9 Submitted By: Joe Wreschnig (piman) Assigned to: Bob Ippolito (etrepum) Summary: struct.pack raises TypeError where it used to convert Initial Comment: piman at toybox:~$ python2.4 -c "import struct; struct.pack('>H', 1.0)" piman at toybox:~$ python2.5 -c "import struct; struct.pack('>H', 1.0)" Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/struct.py", line 63, in pack return o.pack(*args) TypeError: unsupported operand type(s) for &: 'float' and 'long' This might have appeared as part of the struct optimizations; if struct isn't going to convert anymore for performance reasons, I think this should be mentioned in the release notes. Though personally I would prefer struct go back to converting its arguments. ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2006-08-02 22:10 Message: Logged In: YES user_id=139309 I've attached a patch which should resolve this issue. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-28 23:21 Message: Logged In: YES user_id=33168 I'd like to see a deprecation warning so old code continues to work. struct is way to loose and needs to be tightened up, but that might not fully happen until py3k. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-28 15:44 Message: Logged In: YES user_id=849994 I think that's a question for python-dev. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-07-28 15:31 Message: Logged In: YES user_id=139309 That wasn't really intentional, but the old behavior looks a bit suspect: $ python2.4 -c "import struct; print repr(struct.pack('>H', 1.6))" '\x00\x01' We could change it to check for floats and do a DeprecationWarning? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-28 14:51 Message: Logged In: YES user_id=849994 Bob? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470 From noreply at sourceforge.net Thu Aug 3 06:09:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 21:09:26 -0700 Subject: [ python-Bugs-1532726 ] incorrect behaviour of PyUnicode_EncodeMBCS? Message-ID: Bugs item #1532726, was opened at 2006-08-01 14:20 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532726&group_id=5470 Please note that this 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: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jan-Willem (jwnmulder) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect behaviour of PyUnicode_EncodeMBCS? Initial Comment: Using python 2.4.3 This behaviour is not reproducable on a window or linux machine. I found the bug when trying to find a problem on python 2.4.3 ported to the xbox. running the next two commands test_string = 'encode me' print repr(test_string.encode('mbcs')) results on windows in : 'encode me' and on the xbox : 'encode me\\x00' The problem is that 'PyUnicode_EncodeMBCS' returns an PyStringObject that contains the data 'encode me' but with an object size of 10. string_repr(test_string) assumes the string contains a 0 character and encodes it as '\\x00' looking at the function 'PyUnicode_EncodeMBCS(const Py_UNICODE *p, int size, const char *errors)' there are basicly two functions { mbcssize = WideCharToMultiByte(CP_ACP, 0, p, size, NULL, 0, NULL, NULL); repr = PyString_FromStringAndSize(NULL, mbcssize); } WideCharToMultiByte returns the nummer of bytes needed for the buffer, because of the string termination this functions returns 10. PyString_FromStringAndSize assumes its second argument to be the number of needed characters, not bytes. So an easy fix would be to change repr = PyString_FromStringAndSize(NULL, mbcssize); in repr = PyString_FromStringAndSize(NULL, mbcssize - 1); Just checked the 2.4.3 svn trunk and it contains the same bug. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-02 21:09 Message: Logged In: YES user_id=33168 Thanks for letting us know. Closing as requested. ---------------------------------------------------------------------- Comment By: Jan-Willem (jwnmulder) Date: 2006-08-02 10:44 Message: Logged In: YES user_id=770969 and the result for the xbox 10 101 110 99 111 100 101 32 109 101 0 11 101 110 99 111 100 101 32 109 101 0 0 It seems the xbox calculates an extra character for a '\0' count(L"encode me", -1); results on both platforms in ret = 10 So I think this bug can be closed and clasified as an xbox bug... Not so hard for us to fix, almost all api calls for dlls are emulated in our application, so it is easy enough to put a fix in for us. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-08-01 22:31 Message: Logged In: YES user_id=1200846 I think this is not related to that patch. On my win2000sp4, teminating null character is not passed to PyUnicode_EncodeMBCS. ////////////////////////////////////////////// // patch for debug (release24-maint branch) Index: Objects/unicodeobject.c =================================================================== --- Objects/unicodeobject.c (revision 51033) +++ Objects/unicodeobject.c (working copy) @@ -2782,6 +2782,20 @@ char *s; DWORD mbcssize; +{ /* debug */ + + int i; + + printf("------------> %d\n", size); + + for (i = 0; i < size; ++i) { + printf("%d ", (int)p[i]); + } + + printf("\n"); + +} /* debug */ + /* If there are no characters, bail now! */ if (size==0) return PyString_FromString(""); ////////////////////////////////// // a.py test_string = 'encode me' print repr(test_string.encode('mbcs')) ////////////////////////////////// // result R:\>py a.py ------------> 9 101 110 99 111 100 101 32 109 101 'encode me' [7660 refs] And I tried this. #include #include #include void count(LPCWSTR w, int size) { char *buf; int i; const int ret = ::WideCharToMultiByte( CP_ACP, 0, w, size, NULL, 0, NULL, NULL ); if (ret == 0) { printf("error\n"); } else { printf("%d\n", ret); } buf = (char*)malloc(ret); ::WideCharToMultiByte( CP_ACP, 0, w, size, buf, ret, NULL, NULL ); for (i = 0; i < ret; ++i) { printf("%d ", (int)buf[i]); } printf("\n"); free(buf); } int main() { count(L"encode me", 9); count(L"encode me", 10); /* include null charater */ } /* 9 101 110 99 111 100 101 32 109 101 10 101 110 99 111 100 101 32 109 101 0 */ As stated in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_2bj9.asp , WideCharToMultiByte never output null character if source string doesn't contain null character. So I think usage of WideCharToMultiByte is correct. I don't know why, but probably some behavior difference should exist between win2000 and xbox. (ie: xbox calls PyUnicode_EncodeMBCS with size 10 ... or WideCharToMultiByte on xbox outputs null character even if source string doesn't contain it?) Can you try above C code and debug patch on xbox? ---------------------------------------------------------------------- Comment By: Jan-Willem (jwnmulder) Date: 2006-08-01 14:30 Message: Logged In: YES user_id=770969 related to patch 1455898 ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532726&group_id=5470 From noreply at sourceforge.net Thu Aug 3 06:23:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 21:23:33 -0700 Subject: [ python-Bugs-1531405 ] format_exception raises if str(exception) raises Message-ID: Bugs item #1531405, was opened at 2006-07-30 14:06 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470 Please note that this 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: 9 Submitted By: Jp Calderone (kuran) >Assigned to: Neal Norwitz (nnorwitz) Summary: format_exception raises if str(exception) raises Initial Comment: Previously format_exception_only used _some_str() to find the string representation of an exception. In current trunk at HEAD that code has been factored into _format_final_exc_line and changed in two ways: it now calls str(exception) twice instead of once and in one of those cases, it calls str() directly rather than through _some_str, which does exception handling. The end result of this is that application-level code which uses the traceback module to format exceptions which previously could not raise exceptions now can raise exceptions. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-08-02 15:55 Message: Logged In: YES user_id=366566 I don't think those are related. To clarify, this is the case I am talking about: Python 2.5b2 (trunk:50989, Jul 30 2006, 15:42:25) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X: ... def __str__(self): 1/0 ... >>> import traceback >>> traceback.format_exception_only(X, X()) Traceback (most recent call last): File "", line 1, in File "/home/exarkun/Projects/python/trunk/Lib/traceback.py", line 179, in format_exception_only return [_format_final_exc_line(stype, value)] File "/home/exarkun/Projects/python/trunk/Lib/traceback.py", line 205, in _format_final_exc_line if value is None or not str(value): File "", line 2, in __str__ ZeroDivisionError: integer division or modulo by zero >>> Compare this to the Python 2.4 output: Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X: ... def __str__(self): 1/0 ... >>> import traceback >>> traceback.format_exception_only(X, X()) ['X: \n'] >>> ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-02 15:13 Message: Logged In: YES user_id=764593 Jp -- is this the same issue as 1515163 (patch 1515343)? If so, it should be cleared up in the traceback.py from head. Could you doublecheck? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470 From noreply at sourceforge.net Thu Aug 3 07:17:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 22:17:01 -0700 Subject: [ python-Bugs-1532483 ] the csv module writes files that Excel sees as SYLK files Message-ID: Bugs item #1532483, was opened at 2006-08-01 14:52 Message generated for change (Comment added) made by madewokherd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532483&group_id=5470 Please note that this 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: Vincent Povirk (madewokherd) Assigned to: Skip Montanaro (montanaro) Summary: the csv module writes files that Excel sees as SYLK files Initial Comment: I'm using python version 2.4.3 Apparently, when Excel 2003 reads a file, it looks for the identifying string "ID" at the beginning of the file. If it finds this string, it assumes it's reading an SYLK file (see http://netghost.narod.ru/gff/graphics/summary/micsylk.htm for some information on SYLK). The csv module will generate a file that starts with ID if the first field it writes starts with ID and does not need to be quoted. When Excel tries to open the file, the following message pops up: "Excel has detected that 'test.csv' is a SYLK file, but cannot load it. Either the file has errors or it is not a SYLK file format. Click OK to try to open the file in a different format." Excel can read the file after clicking OK. Excel actually has the same problem with CSV files it has written. Even so, when using the 'excel' dialect, csv should write files that Excel can open without any problems. It could do this by quoting the first field in the file if it begins with "ID". Unfortunately, csv's Dialect class does not make this possible. I'm currently working around it by using QUOTE_NONNUMERIC. ---------------------------------------------------------------------- >Comment By: Vincent Povirk (madewokherd) Date: 2006-08-03 05:17 Message: Logged In: YES user_id=553355 It does, and that's what I've been doing. I can't believe I failed to mention it. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-02 13:28 Message: Logged In: YES user_id=44345 Vincent, A simple workaround would be to define a fully quoting dialect: class quoted_excel(csv.excel): quoting=csv.QUOTE_NONNUMERIC # or QUOTE_ALL That would cause your generated CSV files to start with a quote character, e.g.: "ID","FOO" 1,"bar" 2,"bAz" Try that and see if it makes Excel 2003 happy. Skip ---------------------------------------------------------------------- Comment By: Vincent Povirk (madewokherd) Date: 2006-08-01 18:01 Message: Logged In: YES user_id=553355 Thanks for your response. Yes, it's definitely a bug in Excel 2003 (as it also complains about files it saved). I do not have a later version of Excel to test. Microsoft has a page about this issue that seems to say 2003 is the last version with that problem: http://support.microsoft.com/kb/323626/ Their solution is worse than the problem, I'd be interested in seeing how a later version behaves. I know that if the first cell is quoted, Excel will open it without complaining. I think the best solution would be to quote the first cell if it starts with ID by introducing a new QUOTE_ constant. I don't know how that part of the code works (I'm too lazy to read things that aren't written in python); maybe it's more reasonable to quote any field starting with ID. I don't know of any other uses that would break, but I'm not in touch with many csv users. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-01 16:22 Message: Logged In: YES user_id=44345 Seems like a shortcoming in Excel 2003 to me, not a problem with the csv module. Still, if you can suggest a change that won't break many other uses of the csv module's output, I'll consider it. Have you tried the same test with a later version of Excel? Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532483&group_id=5470 From noreply at sourceforge.net Thu Aug 3 07:59:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 22:59:10 -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 nnorwitz 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: Neal Norwitz (nnorwitz) 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: Neal Norwitz (nnorwitz) Date: 2006-08-02 22:59 Message: Logged In: YES user_id=33168 Fix pending. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2006-04-03 08:31 Message: Logged In: YES user_id=31392 Just wanted to note that I have fixes for the failing tests on my laptop. Need to sync with the current trunk before I can check in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-10-25 15:03 Message: Logged In: YES user_id=357491 Yep, all tests pass, so that just leaves the test_trace tests that are currently commented out. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-10-23 21:51 Message: Logged In: YES user_id=35752 I believe the only remaining broken tests are the ones commented out in test_trace. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2005-10-07 11:46 Message: Logged In: YES user_id=31392 test_dis update: Fixed one of two failing tests. test_dis() was easy. test_bug_708901() is harder. The current AST only stores line numbers for statements. The test case is checking that the lnotab can assign a single statement multiple line numbers; in this case, the statement spans multiple lines and the disassembled code should reflect that. The fix is probably to add line numbers to expressions, which requires changing the AST definition and updating ast.c to assign line numbers. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2005-10-07 11:01 Message: Logged In: YES user_id=31392 Here's a quick status report on Linux + GCC 3.2.2 from today: 12 tests failed: test_dis test_doctest test_future test_genexps test_inspect test_new test_peepholer test_pwd test_scope test_subprocess test_symtable test_trace 7 skips unexpected on linux2: test_hotshot test_bsddb test_email test_parser test_transformer test_email_codecs test_compiler I'm going to trace into the details of why each of these tests is failing. ---------------------------------------------------------------------- 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 Thu Aug 3 08:03:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 23:03:33 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 01:47 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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: nomind (vnainar) Assigned to: A.M. Kuchling (akuchling) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-02 23:03 Message: Logged In: YES user_id=33168 Andrew, could you apply this after the freeze is over? ---------------------------------------------------------------------- Comment By: Paul Smedley (psmedley) Date: 2006-05-21 07:38 Message: Logged In: YES user_id=1359962 I have a similar problem on OS/2. When running any script that uses curses I get: [U:\dev\Python-2.4.3\PC\os2emx]python test_curses.py Traceback (most recent call last): File "test_curses.py", line 242, in ? curses.wrapper(main) File "U:/DEV/PYTHON-2.4.3/Lib/curses/wrapper.py", line 49, in wrapper curses.nocbreak() _curses.error: nocbreak() returned ERR If I remove the reference to nocbreak() from wrapper.py, I get the same error but in endwin(), removing endwin() from wrapper.py, I get an error in cbreak(), removing cbreak() then some scripts work. For example, from the demo folder, all work exceptlife.py & xmas.py, which both return an error "_curses.error: nocbreak() returned ERR" on various line numbers. Seems certain curses functions are working correctly, others aren't. The patch in this bug does NOT make any difference here. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-17 11:50 Message: Logged In: YES user_id=1497957 /me confirms ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-15 08:30 Message: Logged In: YES user_id=21627 Good spotting! Can everybody please confirm that the attached patch fixes the problem? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-15 07:48 Message: Logged In: YES user_id=1497957 Half day of debugging and it seems that I found an answer... just by accident ;). When curses module is linked against ncursesw it seems that it also should be linked against panelw not plain panel. After changing this in setup.py, ncurses.py demo finally runs fine. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-15 00:05 Message: Logged In: YES user_id=21627 I couldn't reproduce the problem on a Linux console (although my console had a different size); so it remains unreproducable for me. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-13 04:00 Message: Logged In: YES user_id=1493752 Well , it is the linux console (in VGA mode ). The local is en_US.The size of the console is 100X37. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-10 22:32 Message: Logged In: YES user_id=21627 Ah, ok. vnainar, atler_: What terminal had you been using to make it crash? What is your locale? Any other conditions that might be relevant (e.g. dimension of the terminal)? ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-10 22:13 Message: Logged In: YES user_id=1493752 Removing 'ncursesw' (there are two references to it in 'setup.py') seems to solve the problem. I noticed one more oddity. Even before the above recompilation , it ran fine on an Xterm ! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-10 15:28 Message: Logged In: YES user_id=21627 That's hard to tell. Somebody would have to debug ncurses to find out why it crashes. Notice that it crashes only on some installations, so it is likely rather a problem with your ncurses installation, than with Python (or even with ncurses itself). ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-10 14:24 Message: Logged In: YES user_id=1497957 loewis: removing lines refering to ncursesw solves the problem. ncurses.py runs fine as well as other programs. What is actual problem then? Something with ncursesw or with python? Anyway, Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-09 13:58 Message: Logged In: YES user_id=21627 atler_: around line 427, you find if self.compiler.find_library_file(lib_dirs, 'ncursesw'): readline_libs.append('ncursesw') elif self.compiler.find_library_file(lib_dirs, 'ncurses'): Replace that with if self.compiler.find_library_file(lib_dirs, 'ncurses'): (i.e. dropping the ncursesw part), and rebuild. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 06:48 Message: Logged In: YES user_id=1497957 More complete backtrace, I hope it will help: http://pastebin.com/649445 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 05:14 Message: Logged In: YES user_id=29957 The buildbot boxes don't show this problem. You might need to rebuild a Python with -g and unstripped to get a useful backtrace. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 03:51 Message: Logged In: YES user_id=1497957 $ ldd /usr/lib/python2.4/lib-dynload/_curses.so libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x7004c000) libpthread.so.0 => /lib/libpthread.so.0 (0x70080000) libc.so.6 => /lib/libc.so.6 (0x700e4000) libdl.so.2 => /lib/libdl.so.2 (0x70228000) libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000) /lib/ld-linux.so.2 (0x70000000) ... Program received signal SIGSEGV, Segmentation fault. 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 gdb) bt #0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 #1 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so #2 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so Previous frame identical to this frame (corrupt stack?) It seems that only programs using panel library cause segfaults (all other demos run fine except ncurses.py), sorry for a mistake in a last post. loewis: I'm not sure I understand second point. What excatly should be changed in setup.py? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-09 03:46 Message: Logged In: YES user_id=1126061 Cannot reproduce on Gentoo. All the files in the Demo/curses directory run fine. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-09 03:29 Message: Logged In: YES user_id=21627 I can't reproduce any of this on Debian; Demo/curses/ncurses.py runs fine. Can you please 1. run ldd on _curses.so, and report the output, and 2. edit setup.py, removing the lines that deal with ncursesw, 3. atler_: produce a gdb backtrace on the time of the crash, 4: vnainar: please report what you mean by "does not work". Does it erase your hard disk? turn off the machine? Paint things blue instead of red? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 03:06 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-05 22:38 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-04 15:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Thu Aug 3 08:13:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Aug 2006 23:13:22 -0700 Subject: [ python-Bugs-1531405 ] format_exception raises if str(exception) raises Message-ID: Bugs item #1531405, was opened at 2006-07-30 21:06 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470 Please note that this 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: 9 Submitted By: Jp Calderone (kuran) Assigned to: Neal Norwitz (nnorwitz) Summary: format_exception raises if str(exception) raises Initial Comment: Previously format_exception_only used _some_str() to find the string representation of an exception. In current trunk at HEAD that code has been factored into _format_final_exc_line and changed in two ways: it now calls str(exception) twice instead of once and in one of those cases, it calls str() directly rather than through _some_str, which does exception handling. The end result of this is that application-level code which uses the traceback module to format exceptions which previously could not raise exceptions now can raise exceptions. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-03 06:13 Message: Logged In: YES user_id=849994 I have a fix and will apply as soon as trunk is unfrozen. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-08-02 22:55 Message: Logged In: YES user_id=366566 I don't think those are related. To clarify, this is the case I am talking about: Python 2.5b2 (trunk:50989, Jul 30 2006, 15:42:25) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X: ... def __str__(self): 1/0 ... >>> import traceback >>> traceback.format_exception_only(X, X()) Traceback (most recent call last): File "", line 1, in File "/home/exarkun/Projects/python/trunk/Lib/traceback.py", line 179, in format_exception_only return [_format_final_exc_line(stype, value)] File "/home/exarkun/Projects/python/trunk/Lib/traceback.py", line 205, in _format_final_exc_line if value is None or not str(value): File "", line 2, in __str__ ZeroDivisionError: integer division or modulo by zero >>> Compare this to the Python 2.4 output: Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X: ... def __str__(self): 1/0 ... >>> import traceback >>> traceback.format_exception_only(X, X()) ['X: \n'] >>> ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-02 22:13 Message: Logged In: YES user_id=764593 Jp -- is this the same issue as 1515163 (patch 1515343)? If so, it should be cleared up in the traceback.py from head. Could you doublecheck? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470 From noreply at sourceforge.net Thu Aug 3 09:26:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 00:26:59 -0700 Subject: [ python-Bugs-1333982 ] Bugs of the new AST compiler Message-ID: Bugs item #1333982, was opened at 2005-10-21 03:08 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: AST Status: Open Resolution: None Priority: 9 Submitted By: Armin Rigo (arigo) >Assigned to: Neal Norwitz (nnorwitz) Summary: Bugs of the new AST compiler Initial Comment: The newly merged AST branch is likely to expose a number of small problems before it stabilizes, so here is a tentative bug tracker entry to collect such small problems. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-03 00:26 Message: Logged In: YES user_id=33168 Fix pending. need tests and code to be thawed. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2006-07-09 14:23 Message: Logged In: YES user_id=35752 Unary minus bug has been fixed in SVN rev 50495. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2006-07-09 14:05 Message: Logged In: YES user_id=35752 Regarding the -2147483648 bug: the old compiler tries to fold unary +, - and ~ if the RHS is a constant. I think only the minus case is important since the others are just optimizations, right? Attaching what seems to be a minimum fix. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-02 04:29 Message: Logged In: YES user_id=4771 Attached a patch for the LOAD_CONST POP_TOP optimization (modified from Georg Brandl on python-dev). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-04-11 02:41 Message: Logged In: YES user_id=6656 Good morning Armin! I've reported that bug already: http://python.org/sf/1441486 There's a patch which purports to fix it: http://python.org/sf/1446922 but I haven't gotten around to testing it. (this is running the pypy/module/array tests or something, isn't it?) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-04-11 01:45 Message: Logged In: YES user_id=4771 Another one: the literal -2147483648 (i.e. the value of -sys.maxint-1) gives a long in 2.5, but an int in <= 2.4. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-03 00:30 Message: Logged In: YES user_id=33168 The tuple store problem is fixed. The only outstanding item is the LOAD_CONST/POP_TOP. I will fix that soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-17 22:56 Message: Logged In: YES user_id=33168 Jeremy, there's no need to read anything before my last comment at 2005-12-17 23:10. The last two by Armin, Michael, then my last comment are the only important ones. Everything that occurred before my 2005-12-17 comment was taken care of AFAIK. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-02-12 13:54 Message: Logged In: YES user_id=4771 Subscripting is generally a bit sloppy: e.g. the AST model has no way to distinguish between a single value and a one-element tuple value! See: >>> d = {} >>> d[1,] = 6 >>> d {1: 6} # ! I suggest we fix the model to turn the 'subs' of the 'Subscript' node from a list of nodes to a single, mandatory 'sub' node. If tupling is necessary, it can be explicitly represented with a 'sub' containing a 'Tuple' node. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-02-09 07:02 Message: Logged In: YES user_id=6656 We found another one. Something is wrong in the compilation of augmented assignment to subscriptions containing tuples; running this code: class C: def __setitem__(self, i, v): print i, v def __getitem__(self, i): print i return 0 c = C() c[4,5] += 1 gives a spurious exception: Traceback (most recent call last): File "", line 1, in TypeError: object does not support item assignment By contrast, "c[(4,5)] += 1" works fine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-17 23:10 Message: Logged In: YES user_id=33168 EXTENDED_ARG problem was fixed a while ago. The assert/pass problem was fixed with: 41756. That leaves the LOAD_CONST/POP_TOP optimization that was lost and one compiler warning: marshal_write_mod() not being used. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-10 16:41 Message: Logged In: YES user_id=6656 You have to include those lines in a source file. It still crashes for me. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-12-10 15:44 Message: Logged In: YES user_id=357491 I just checked Armin's problem code on rev. 41638 and it worked for me in the interpreter. You still having problems, Armin? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-04 02:30 Message: Logged In: YES user_id=4771 At rev 41584, the following code snippet triggers an assert if --with-pydebug is enabled: Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed ----------------------- assert 1, ([s for s in x] + [s for s in x]) pass ----------------------- ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-23 12:14 Message: Logged In: YES user_id=33168 Checkpoint of outstanding issues. I think all the others mentioned so far have been fixed: * Raymond's warnings in compile.c (unused locals are fixed) * EXTENDED_ARG problem * LOAD_CONST/POP_TOP (note we can fix this in the optimizer generally which would get rid of other useless code too) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-22 21:53 Message: Logged In: YES user_id=80475 FWIW, here are the warnings issued by my compiler: Python-ast.c C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2085) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2130) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2151) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2261) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2270) : warning C4101: 'i' : unreferenced local variable compile.c C:\py25\Python\compile.c(3782) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3802) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3806) : warning C4305: '=' : truncation from 'const int ' to 'char ' ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-22 00:28 Message: Logged In: YES user_id=33168 I assigned to Jeremy and Neil in the hopes they will see this message and know about these problems. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:45 Message: Logged In: YES user_id=4771 The following (similarly strange-looking) code snippets compiled successfully before, now they give SyntaxErrors: -------------------- def f(): class g: exec "hi" x -------------------- def f(x): class g: exec "hi" x -------------------- def f(): class g: from a import * x -------------------- def f(x): class g: from a import * x ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:33 Message: Logged In: YES user_id=4771 I would suspect the following one to be due to incorrect handling of EXTENDED_ARG -- it's from a PyPy test about that: longexpr = 'x = x or ' + '-x' * 2500 code = ''' def f(x): %s %s %s %s %s %s %s %s %s %s while x: x -= 1 # EXTENDED_ARG/JUMP_ABSOLUTE here return x ''' % ((longexpr,)*10) exec code f(5) SystemError: unknown opcode dis.dis() shows that the target of both the SETUP_LOOP and the JUMP_IF_FALSE at the start of the loop are wrong. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:15 Message: Logged In: YES user_id=4771 The Python rules about which names get mangled are a bit insane. I share mwh's view that mangling should never have been invented in the first place, but well: >>> def f(): ... __x = 5 ... class X: ... def g(self): ... return __x ... return X ... Fatal Python error: unknown scope for _X__x in X(135832776) in ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:01 Message: Logged In: YES user_id=4771 For reference, an optimization that got lost: def f(): 'a' 'b' 'a' is the docstring, but the 'b' previously did not show up anywhere in the code object. Now there is the LOAD_CONST/POP_TOP pair. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 04:54 Message: Logged In: YES user_id=4771 any reason why lambda functions have a __name__ of 'lambda' now instead of '' ? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 03:22 Message: Logged In: YES user_id=4771 import a as b, c the 'c' part gets completely forgotten and there is no 'IMPORT_NAME c' in the bytecode. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 03:13 Message: Logged In: YES user_id=4771 A scoping problem (comparing with the old compiler): class X: print hello The variable 'hello' is incorrectly looked up with LOAD_GLOBAL instead of LOAD_NAME. It causes a crash in PyPy in a case where the name 'hello' is stored into the class implicitely (via locals()). It can probably be discussed if the bug is in PyPy, but it is a difference in behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 From noreply at sourceforge.net Thu Aug 3 09:39:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 00:39:42 -0700 Subject: [ python-Bugs-1525343 ] Webserver TypeError: expected read buffer, NoneType found Message-ID: Bugs item #1525343, was opened at 2006-07-19 16:53 Message generated for change (Comment added) made by jbeisert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525343&group_id=5470 Please note that this 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: jbet (jbeisert) Assigned to: Nobody/Anonymous (nobody) Summary: Webserver TypeError: expected read buffer, NoneType found Initial Comment: When I'm using the python webserver I got the following message for every access by my client. Soryy, I have no experience in Python, so I cannot help. This is only a report. HTTPdaemon_v1.0.0 listening on port 8001 ---------------------------------------- Exception happened during processing of request from ('192.168.1.9', 33917) Traceback (most recent call last): File "/home/jb/bin/lib/python2.5/SocketServer.py", line 463, in process_request_thread self.finish_request(request, client_address) File "/home/jb/bin/lib/python2.5/SocketServer.py", line 254, in finish_request self.RequestHandlerClass(request, client_address, self) File "/home/jb/bin/lib/python2.5/SocketServer.py", line 521, in __init__ self.handle() File "/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line 316, in handle self.handle_one_request() File "/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line 310, in handle_one_request method() File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 53, in do_GET self.handle_request() File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 56, in handle_request httpreq = HSHTTPRequest(self) File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 254, in __init__ keep_blank_values = True File "/home/jb/bin/lib/python2.5/cgi.py", line 462, in __init__ fp = StringIO(qs) TypeError: expected read buffer, NoneType found ---------------------------------------- ---------------------------------------- Exception happened during processing of request from ('192.168.1.9', 33918) Traceback (most recent call last): File "/home/jb/bin/lib/python2.5/SocketServer.py", line 463, in process_request_thread self.finish_request(request, client_address) File "/home/jb/bin/lib/python2.5/SocketServer.py", line 254, in finish_request self.RequestHandlerClass(request, client_address, self) File "/home/jb/bin/lib/python2.5/SocketServer.py", line 521, in __init__ self.handle() File "/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line 316, in handle self.handle_one_request() File "/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line 310, in handle_one_request method() File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 53, in do_GET self.handle_request() File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 56, in handle_request httpreq = HSHTTPRequest(self) File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 254, in __init__ keep_blank_values = True File "/home/jb/bin/lib/python2.5/cgi.py", line 462, in __init__ fp = StringIO(qs) TypeError: expected read buffer, NoneType found ---------------------------------------- ---------------------------------------------------------------------- >Comment By: jbet (jbeisert) Date: 2006-08-03 09:39 Message: Logged In: YES user_id=1558389 > Can I ask how you came to use the > as-yet-unreleased Python 2.5 if > you have no experience with Python? We are using Myghty as a webserver, but we have the problem python 2.4 eats up all the memory of the small embedded system. So I tried with python 2.5 with the new memory management...and was stuck at this message. I reported this message to improve 2.5 development. Sorry if this was a wrong way to do it. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-03 00:04 Message: Logged In: YES user_id=764593 I suspect that changing >>> fp = StringIO(qs) to >>> fp = StringIO(qs or "") would fix the problem. If so, this is arguably a bug in myghty. qs was already set to "" unless sys.argv[1] or environ['QUERY_STRING']had a value. Neither of these should ever be None. (They should be either a string, or not found.) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-08-01 21:04 Message: Logged In: YES user_id=340931 Thanks for the report. Can I ask how you came to use the as-yet-unreleased Python 2.5 if you have no experience with Python? It looks like you are having this problem with Myghty. Does that require Python 2.5? FWIW, this looks to me like a problem with Myghty's use of the cgi module, not a problem with Python itself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525343&group_id=5470 From noreply at sourceforge.net Thu Aug 3 09:55:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 00:55:25 -0700 Subject: [ python-Bugs-1532726 ] incorrect behaviour of PyUnicode_EncodeMBCS? Message-ID: Bugs item #1532726, was opened at 2006-08-02 06:20 Message generated for change (Comment added) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532726&group_id=5470 Please note that this 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: 3rd Party Status: Closed Resolution: Invalid Priority: 5 Submitted By: Jan-Willem (jwnmulder) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect behaviour of PyUnicode_EncodeMBCS? Initial Comment: Using python 2.4.3 This behaviour is not reproducable on a window or linux machine. I found the bug when trying to find a problem on python 2.4.3 ported to the xbox. running the next two commands test_string = 'encode me' print repr(test_string.encode('mbcs')) results on windows in : 'encode me' and on the xbox : 'encode me\\x00' The problem is that 'PyUnicode_EncodeMBCS' returns an PyStringObject that contains the data 'encode me' but with an object size of 10. string_repr(test_string) assumes the string contains a 0 character and encodes it as '\\x00' looking at the function 'PyUnicode_EncodeMBCS(const Py_UNICODE *p, int size, const char *errors)' there are basicly two functions { mbcssize = WideCharToMultiByte(CP_ACP, 0, p, size, NULL, 0, NULL, NULL); repr = PyString_FromStringAndSize(NULL, mbcssize); } WideCharToMultiByte returns the nummer of bytes needed for the buffer, because of the string termination this functions returns 10. PyString_FromStringAndSize assumes its second argument to be the number of needed characters, not bytes. So an easy fix would be to change repr = PyString_FromStringAndSize(NULL, mbcssize); in repr = PyString_FromStringAndSize(NULL, mbcssize - 1); Just checked the 2.4.3 svn trunk and it contains the same bug. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-08-03 16:55 Message: Logged In: YES user_id=1200846 Sorry, if you don't mind, can you try another program? #include #include #include void count(LPCWSTR w, int size) { char *buf; int i, ret; ret = WideCharToMultiByte( CP_ACP, 0, w, size, NULL, 0, NULL, NULL ); if (ret == 0) { printf("error\n"); return; } printf("required = %d, ", ret); buf = (char*)malloc(ret); ret = WideCharToMultiByte( CP_ACP, 0, w, size, buf, ret, NULL, NULL ); printf("written = %d\n", ret); for (i = 0; i < ret; ++i) { printf("%d ", (int)buf[i]); } printf("\n"); free(buf); } int main() { count(L"encode me", 9); count(L"encode me", 10); } //////////////////////////// // Result on Win2000 R:\>a required = 9, written = 9 101 110 99 111 100 101 32 109 101 required = 10, written = 10 101 110 99 111 100 101 32 109 101 0 On Windows, "required buffer size" equals to "written size" and I thought this is always true. But I noticed that there is not such statements in MSDN document. Maybe on xbox, "required buffer size" is more than really required size like this... //////////////////////////// // Maybe on xbox....? R:\>a required = 10, written = 9 101 110 99 111 100 101 32 109 101 required = 11, written = 10 101 110 99 111 100 101 32 109 101 0 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-03 13:09 Message: Logged In: YES user_id=33168 Thanks for letting us know. Closing as requested. ---------------------------------------------------------------------- Comment By: Jan-Willem (jwnmulder) Date: 2006-08-03 02:44 Message: Logged In: YES user_id=770969 and the result for the xbox 10 101 110 99 111 100 101 32 109 101 0 11 101 110 99 111 100 101 32 109 101 0 0 It seems the xbox calculates an extra character for a '\0' count(L"encode me", -1); results on both platforms in ret = 10 So I think this bug can be closed and clasified as an xbox bug... Not so hard for us to fix, almost all api calls for dlls are emulated in our application, so it is easy enough to put a fix in for us. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-08-02 14:31 Message: Logged In: YES user_id=1200846 I think this is not related to that patch. On my win2000sp4, teminating null character is not passed to PyUnicode_EncodeMBCS. ////////////////////////////////////////////// // patch for debug (release24-maint branch) Index: Objects/unicodeobject.c =================================================================== --- Objects/unicodeobject.c (revision 51033) +++ Objects/unicodeobject.c (working copy) @@ -2782,6 +2782,20 @@ char *s; DWORD mbcssize; +{ /* debug */ + + int i; + + printf("------------> %d\n", size); + + for (i = 0; i < size; ++i) { + printf("%d ", (int)p[i]); + } + + printf("\n"); + +} /* debug */ + /* If there are no characters, bail now! */ if (size==0) return PyString_FromString(""); ////////////////////////////////// // a.py test_string = 'encode me' print repr(test_string.encode('mbcs')) ////////////////////////////////// // result R:\>py a.py ------------> 9 101 110 99 111 100 101 32 109 101 'encode me' [7660 refs] And I tried this. #include #include #include void count(LPCWSTR w, int size) { char *buf; int i; const int ret = ::WideCharToMultiByte( CP_ACP, 0, w, size, NULL, 0, NULL, NULL ); if (ret == 0) { printf("error\n"); } else { printf("%d\n", ret); } buf = (char*)malloc(ret); ::WideCharToMultiByte( CP_ACP, 0, w, size, buf, ret, NULL, NULL ); for (i = 0; i < ret; ++i) { printf("%d ", (int)buf[i]); } printf("\n"); free(buf); } int main() { count(L"encode me", 9); count(L"encode me", 10); /* include null charater */ } /* 9 101 110 99 111 100 101 32 109 101 10 101 110 99 111 100 101 32 109 101 0 */ As stated in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_2bj9.asp , WideCharToMultiByte never output null character if source string doesn't contain null character. So I think usage of WideCharToMultiByte is correct. I don't know why, but probably some behavior difference should exist between win2000 and xbox. (ie: xbox calls PyUnicode_EncodeMBCS with size 10 ... or WideCharToMultiByte on xbox outputs null character even if source string doesn't contain it?) Can you try above C code and debug patch on xbox? ---------------------------------------------------------------------- Comment By: Jan-Willem (jwnmulder) Date: 2006-08-02 06:30 Message: Logged In: YES user_id=770969 related to patch 1455898 ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532726&group_id=5470 From noreply at sourceforge.net Thu Aug 3 12:02:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 03:02:23 -0700 Subject: [ python-Bugs-1524938 ] PEP MemoryError with a lot of available memory gc not called Message-ID: Bugs item #1524938, was opened at 2006-07-19 05:46 Message generated for change (Comment added) made by markmat You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470 Please note that this 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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Mark Matusevich (markmat) Assigned to: Nobody/Anonymous (nobody) Summary: PEP MemoryError with a lot of available memory gc not called Initial Comment: Also the gc behavior is consistent with the documentation, I beleave it is wrong. I think, that Gc should be called automatically before any memory allocation is raised. Example 1: for i in range(700): a = [range(5000000)] a.append(a) print i This example will crash on any any PC with less then 20Gb RAM. On my PC (Windows 2000, 256Mb) it crashes at i==7. Also, this example can be fixed by addition of a call to gc.collect() in the loop, in real cases it may be unreasonable. ---------------------------------------------------------------------- >Comment By: Mark Matusevich (markmat) Date: 2006-08-03 13:02 Message: Logged In: YES user_id=1337765 Another problem related to the above example: there is a time waste due to a memory swap before the MemoryError. Possible solution is to use a dynamic memory limit: GC is called when the limit is reached, then the limit is adjusted according to the memory left. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-03 00:52 Message: Logged In: YES user_id=764593 Doing it everywhere would be a lot of painful changes. Adding the "oops, failed, call gc and try again" to to PyMem_* (currently PyMem_Malloc, PyMem_Realloc, PyMem_New, and PyMem_Resize, but Brett may be changing that) is far more reasonable. Whether it is safe to call gc from there is a different question. ---------------------------------------------------------------------- Comment By: Mark Matusevich (markmat) Date: 2006-07-23 23:19 Message: Logged In: YES user_id=1337765 Sorry, my last comment was to illume (I am slow typer :( ) ---------------------------------------------------------------------- Comment By: Mark Matusevich (markmat) Date: 2006-07-23 23:11 Message: Logged In: YES user_id=1337765 This is exectly what I meant. For my recollection, this is the policy in Java GC. I never had to handle MemoryError in Java, because I knew, that I really do not have any more memory. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-07-23 23:00 Message: Logged In: YES user_id=21627 This is very difficult to implement. The best way might be to introduce yet another allocation function, one that invokes gc before failing, and call that function in all interesting places (of which there are many). Contributions are welcome and should probably start with a PEP first. ---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2006-07-20 02:20 Message: Logged In: YES user_id=2042 Perhaps better than checking before every memory allocation, would be to check once a memory error happens in an allocation. That way there is only the gc hit once there is low memory. So... res = malloc(...); if(!res) { gc.collect(); } res = malloc(...); if(!res) { raise memory error. } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470 From noreply at sourceforge.net Thu Aug 3 12:50:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 03:50:46 -0700 Subject: [ python-Bugs-1532726 ] incorrect behaviour of PyUnicode_EncodeMBCS? Message-ID: Bugs item #1532726, was opened at 2006-08-01 23:20 Message generated for change (Comment added) made by jwnmulder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532726&group_id=5470 Please note that this 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: 3rd Party Status: Closed Resolution: Invalid Priority: 5 Submitted By: Jan-Willem (jwnmulder) Assigned to: Nobody/Anonymous (nobody) Summary: incorrect behaviour of PyUnicode_EncodeMBCS? Initial Comment: Using python 2.4.3 This behaviour is not reproducable on a window or linux machine. I found the bug when trying to find a problem on python 2.4.3 ported to the xbox. running the next two commands test_string = 'encode me' print repr(test_string.encode('mbcs')) results on windows in : 'encode me' and on the xbox : 'encode me\\x00' The problem is that 'PyUnicode_EncodeMBCS' returns an PyStringObject that contains the data 'encode me' but with an object size of 10. string_repr(test_string) assumes the string contains a 0 character and encodes it as '\\x00' looking at the function 'PyUnicode_EncodeMBCS(const Py_UNICODE *p, int size, const char *errors)' there are basicly two functions { mbcssize = WideCharToMultiByte(CP_ACP, 0, p, size, NULL, 0, NULL, NULL); repr = PyString_FromStringAndSize(NULL, mbcssize); } WideCharToMultiByte returns the nummer of bytes needed for the buffer, because of the string termination this functions returns 10. PyString_FromStringAndSize assumes its second argument to be the number of needed characters, not bytes. So an easy fix would be to change repr = PyString_FromStringAndSize(NULL, mbcssize); in repr = PyString_FromStringAndSize(NULL, mbcssize - 1); Just checked the 2.4.3 svn trunk and it contains the same bug. ---------------------------------------------------------------------- >Comment By: Jan-Willem (jwnmulder) Date: 2006-08-03 12:50 Message: Logged In: YES user_id=770969 Sure, but it will have to wait a few days since its time for a holliday now. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-08-03 09:55 Message: Logged In: YES user_id=1200846 Sorry, if you don't mind, can you try another program? #include #include #include void count(LPCWSTR w, int size) { char *buf; int i, ret; ret = WideCharToMultiByte( CP_ACP, 0, w, size, NULL, 0, NULL, NULL ); if (ret == 0) { printf("error\n"); return; } printf("required = %d, ", ret); buf = (char*)malloc(ret); ret = WideCharToMultiByte( CP_ACP, 0, w, size, buf, ret, NULL, NULL ); printf("written = %d\n", ret); for (i = 0; i < ret; ++i) { printf("%d ", (int)buf[i]); } printf("\n"); free(buf); } int main() { count(L"encode me", 9); count(L"encode me", 10); } //////////////////////////// // Result on Win2000 R:\>a required = 9, written = 9 101 110 99 111 100 101 32 109 101 required = 10, written = 10 101 110 99 111 100 101 32 109 101 0 On Windows, "required buffer size" equals to "written size" and I thought this is always true. But I noticed that there is not such statements in MSDN document. Maybe on xbox, "required buffer size" is more than really required size like this... //////////////////////////// // Maybe on xbox....? R:\>a required = 10, written = 9 101 110 99 111 100 101 32 109 101 required = 11, written = 10 101 110 99 111 100 101 32 109 101 0 ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-03 06:09 Message: Logged In: YES user_id=33168 Thanks for letting us know. Closing as requested. ---------------------------------------------------------------------- Comment By: Jan-Willem (jwnmulder) Date: 2006-08-02 19:44 Message: Logged In: YES user_id=770969 and the result for the xbox 10 101 110 99 111 100 101 32 109 101 0 11 101 110 99 111 100 101 32 109 101 0 0 It seems the xbox calculates an extra character for a '\0' count(L"encode me", -1); results on both platforms in ret = 10 So I think this bug can be closed and clasified as an xbox bug... Not so hard for us to fix, almost all api calls for dlls are emulated in our application, so it is easy enough to put a fix in for us. ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-08-02 07:31 Message: Logged In: YES user_id=1200846 I think this is not related to that patch. On my win2000sp4, teminating null character is not passed to PyUnicode_EncodeMBCS. ////////////////////////////////////////////// // patch for debug (release24-maint branch) Index: Objects/unicodeobject.c =================================================================== --- Objects/unicodeobject.c (revision 51033) +++ Objects/unicodeobject.c (working copy) @@ -2782,6 +2782,20 @@ char *s; DWORD mbcssize; +{ /* debug */ + + int i; + + printf("------------> %d\n", size); + + for (i = 0; i < size; ++i) { + printf("%d ", (int)p[i]); + } + + printf("\n"); + +} /* debug */ + /* If there are no characters, bail now! */ if (size==0) return PyString_FromString(""); ////////////////////////////////// // a.py test_string = 'encode me' print repr(test_string.encode('mbcs')) ////////////////////////////////// // result R:\>py a.py ------------> 9 101 110 99 111 100 101 32 109 101 'encode me' [7660 refs] And I tried this. #include #include #include void count(LPCWSTR w, int size) { char *buf; int i; const int ret = ::WideCharToMultiByte( CP_ACP, 0, w, size, NULL, 0, NULL, NULL ); if (ret == 0) { printf("error\n"); } else { printf("%d\n", ret); } buf = (char*)malloc(ret); ::WideCharToMultiByte( CP_ACP, 0, w, size, buf, ret, NULL, NULL ); for (i = 0; i < ret; ++i) { printf("%d ", (int)buf[i]); } printf("\n"); free(buf); } int main() { count(L"encode me", 9); count(L"encode me", 10); /* include null charater */ } /* 9 101 110 99 111 100 101 32 109 101 10 101 110 99 111 100 101 32 109 101 0 */ As stated in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unicode_2bj9.asp , WideCharToMultiByte never output null character if source string doesn't contain null character. So I think usage of WideCharToMultiByte is correct. I don't know why, but probably some behavior difference should exist between win2000 and xbox. (ie: xbox calls PyUnicode_EncodeMBCS with size 10 ... or WideCharToMultiByte on xbox outputs null character even if source string doesn't contain it?) Can you try above C code and debug patch on xbox? ---------------------------------------------------------------------- Comment By: Jan-Willem (jwnmulder) Date: 2006-08-01 23:30 Message: Logged In: YES user_id=770969 related to patch 1455898 ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532726&group_id=5470 From noreply at sourceforge.net Thu Aug 3 13:17:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 04:17:28 -0700 Subject: [ python-Bugs-1532483 ] the csv module writes files that Excel sees as SYLK files Message-ID: Bugs item #1532483, was opened at 2006-08-01 09:52 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532483&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Vincent Povirk (madewokherd) Assigned to: Skip Montanaro (montanaro) Summary: the csv module writes files that Excel sees as SYLK files Initial Comment: I'm using python version 2.4.3 Apparently, when Excel 2003 reads a file, it looks for the identifying string "ID" at the beginning of the file. If it finds this string, it assumes it's reading an SYLK file (see http://netghost.narod.ru/gff/graphics/summary/micsylk.htm for some information on SYLK). The csv module will generate a file that starts with ID if the first field it writes starts with ID and does not need to be quoted. When Excel tries to open the file, the following message pops up: "Excel has detected that 'test.csv' is a SYLK file, but cannot load it. Either the file has errors or it is not a SYLK file format. Click OK to try to open the file in a different format." Excel can read the file after clicking OK. Excel actually has the same problem with CSV files it has written. Even so, when using the 'excel' dialect, csv should write files that Excel can open without any problems. It could do this by quoting the first field in the file if it begins with "ID". Unfortunately, csv's Dialect class does not make this possible. I'm currently working around it by using QUOTE_NONNUMERIC. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 06:17 Message: Logged In: YES user_id=44345 > I can't believe I failed to mention it. Actually, you did: > I'm currently working around it by using QUOTE_NONNUMERIC. I didn't notice it because I was focused on Microsloth's "workaround"... My apologies. I'm closing this as "won't fix". Skip ---------------------------------------------------------------------- Comment By: Vincent Povirk (madewokherd) Date: 2006-08-03 00:17 Message: Logged In: YES user_id=553355 It does, and that's what I've been doing. I can't believe I failed to mention it. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-02 08:28 Message: Logged In: YES user_id=44345 Vincent, A simple workaround would be to define a fully quoting dialect: class quoted_excel(csv.excel): quoting=csv.QUOTE_NONNUMERIC # or QUOTE_ALL That would cause your generated CSV files to start with a quote character, e.g.: "ID","FOO" 1,"bar" 2,"bAz" Try that and see if it makes Excel 2003 happy. Skip ---------------------------------------------------------------------- Comment By: Vincent Povirk (madewokherd) Date: 2006-08-01 13:01 Message: Logged In: YES user_id=553355 Thanks for your response. Yes, it's definitely a bug in Excel 2003 (as it also complains about files it saved). I do not have a later version of Excel to test. Microsoft has a page about this issue that seems to say 2003 is the last version with that problem: http://support.microsoft.com/kb/323626/ Their solution is worse than the problem, I'd be interested in seeing how a later version behaves. I know that if the first cell is quoted, Excel will open it without complaining. I think the best solution would be to quote the first cell if it starts with ID by introducing a new QUOTE_ constant. I don't know how that part of the code works (I'm too lazy to read things that aren't written in python); maybe it's more reasonable to quote any field starting with ID. I don't know of any other uses that would break, but I'm not in touch with many csv users. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-01 11:22 Message: Logged In: YES user_id=44345 Seems like a shortcoming in Excel 2003 to me, not a problem with the csv module. Still, if you can suggest a change that won't break many other uses of the csv module's output, I'll consider it. Have you tried the same test with a later version of Excel? Skip ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532483&group_id=5470 From noreply at sourceforge.net Thu Aug 3 14:53:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 05:53:04 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 04:47 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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: 9 Submitted By: nomind (vnainar) Assigned to: A.M. Kuchling (akuchling) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 08:53 Message: Logged In: YES user_id=11375 Sure. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-03 02:03 Message: Logged In: YES user_id=33168 Andrew, could you apply this after the freeze is over? ---------------------------------------------------------------------- Comment By: Paul Smedley (psmedley) Date: 2006-05-21 10:38 Message: Logged In: YES user_id=1359962 I have a similar problem on OS/2. When running any script that uses curses I get: [U:\dev\Python-2.4.3\PC\os2emx]python test_curses.py Traceback (most recent call last): File "test_curses.py", line 242, in ? curses.wrapper(main) File "U:/DEV/PYTHON-2.4.3/Lib/curses/wrapper.py", line 49, in wrapper curses.nocbreak() _curses.error: nocbreak() returned ERR If I remove the reference to nocbreak() from wrapper.py, I get the same error but in endwin(), removing endwin() from wrapper.py, I get an error in cbreak(), removing cbreak() then some scripts work. For example, from the demo folder, all work exceptlife.py & xmas.py, which both return an error "_curses.error: nocbreak() returned ERR" on various line numbers. Seems certain curses functions are working correctly, others aren't. The patch in this bug does NOT make any difference here. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-17 14:50 Message: Logged In: YES user_id=1497957 /me confirms ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-15 11:30 Message: Logged In: YES user_id=21627 Good spotting! Can everybody please confirm that the attached patch fixes the problem? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-15 10:48 Message: Logged In: YES user_id=1497957 Half day of debugging and it seems that I found an answer... just by accident ;). When curses module is linked against ncursesw it seems that it also should be linked against panelw not plain panel. After changing this in setup.py, ncurses.py demo finally runs fine. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-15 03:05 Message: Logged In: YES user_id=21627 I couldn't reproduce the problem on a Linux console (although my console had a different size); so it remains unreproducable for me. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-13 07:00 Message: Logged In: YES user_id=1493752 Well , it is the linux console (in VGA mode ). The local is en_US.The size of the console is 100X37. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-11 01:32 Message: Logged In: YES user_id=21627 Ah, ok. vnainar, atler_: What terminal had you been using to make it crash? What is your locale? Any other conditions that might be relevant (e.g. dimension of the terminal)? ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-11 01:13 Message: Logged In: YES user_id=1493752 Removing 'ncursesw' (there are two references to it in 'setup.py') seems to solve the problem. I noticed one more oddity. Even before the above recompilation , it ran fine on an Xterm ! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-10 18:28 Message: Logged In: YES user_id=21627 That's hard to tell. Somebody would have to debug ncurses to find out why it crashes. Notice that it crashes only on some installations, so it is likely rather a problem with your ncurses installation, than with Python (or even with ncurses itself). ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-10 17:24 Message: Logged In: YES user_id=1497957 loewis: removing lines refering to ncursesw solves the problem. ncurses.py runs fine as well as other programs. What is actual problem then? Something with ncursesw or with python? Anyway, Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-09 16:58 Message: Logged In: YES user_id=21627 atler_: around line 427, you find if self.compiler.find_library_file(lib_dirs, 'ncursesw'): readline_libs.append('ncursesw') elif self.compiler.find_library_file(lib_dirs, 'ncurses'): Replace that with if self.compiler.find_library_file(lib_dirs, 'ncurses'): (i.e. dropping the ncursesw part), and rebuild. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 09:48 Message: Logged In: YES user_id=1497957 More complete backtrace, I hope it will help: http://pastebin.com/649445 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 08:14 Message: Logged In: YES user_id=29957 The buildbot boxes don't show this problem. You might need to rebuild a Python with -g and unstripped to get a useful backtrace. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 06:51 Message: Logged In: YES user_id=1497957 $ ldd /usr/lib/python2.4/lib-dynload/_curses.so libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x7004c000) libpthread.so.0 => /lib/libpthread.so.0 (0x70080000) libc.so.6 => /lib/libc.so.6 (0x700e4000) libdl.so.2 => /lib/libdl.so.2 (0x70228000) libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000) /lib/ld-linux.so.2 (0x70000000) ... Program received signal SIGSEGV, Segmentation fault. 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 gdb) bt #0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 #1 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so #2 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so Previous frame identical to this frame (corrupt stack?) It seems that only programs using panel library cause segfaults (all other demos run fine except ncurses.py), sorry for a mistake in a last post. loewis: I'm not sure I understand second point. What excatly should be changed in setup.py? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-09 06:46 Message: Logged In: YES user_id=1126061 Cannot reproduce on Gentoo. All the files in the Demo/curses directory run fine. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-09 06:29 Message: Logged In: YES user_id=21627 I can't reproduce any of this on Debian; Demo/curses/ncurses.py runs fine. Can you please 1. run ldd on _curses.so, and report the output, and 2. edit setup.py, removing the lines that deal with ncursesw, 3. atler_: produce a gdb backtrace on the time of the crash, 4: vnainar: please report what you mean by "does not work". Does it erase your hard disk? turn off the machine? Paint things blue instead of red? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 06:06 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-06 01:38 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-04 18:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Thu Aug 3 15:42:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 06:42:49 -0700 Subject: [ python-Bugs-809254 ] imp.find_module doesn't work in /tmp Message-ID: Bugs item #809254, was opened at 2003-09-19 09:44 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809254&group_id=5470 Please note that this 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: Victor T. Ng (vng1) Assigned to: Nobody/Anonymous (nobody) Summary: imp.find_module doesn't work in /tmp Initial Comment: I'm running OSX 10.2.6 and the imp module seems to have a parsing error when I pass it the directory "/" bash$ cd /tmp bash$ touch __init__.py bash$ python Python 2.3 (#2, Jul 30 2003, 11:45:28) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module("tmp",['/']) Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: No module named tmp >>> imp.find_module("tmp",['//']) (None, '//tmp', ('', '', 5)) I'm not sure why, but I seem to need a double slash in the directory name. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 09:42 Message: Logged In: YES user_id=11375 Still present in 2.5 on MacOS; still not present on Linux. ---------------------------------------------------------------------- Comment By: Victor T. Ng (vng1) Date: 2005-01-10 19:32 Message: Logged In: YES user_id=679596 No problems under Python 2.4 on Linux: Python 2.4 (#3, Dec 29 2004, 10:03:34) [GCC 3.3.4 (Debian 1:3.3.4-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module('tmp',['/']) (None, '/tmp', ('', '', 5)) >>> ---------------------------------------------------------------------- Comment By: Victor T. Ng (vng1) Date: 2005-01-10 19:31 Message: Logged In: YES user_id=679596 Affects both Python 2.3 and Python 2.4 on OSX: Python 2.4 (#1, Dec 25 2004, 15:45:34) [GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module('tmp', ['/']) Traceback (most recent call last): File "", line 1, in ? ImportError: No module named tmp >>> ---------------------------------------------------------------------- Comment By: Victor T. Ng (vng1) Date: 2005-01-10 19:29 Message: Logged In: YES user_id=679596 lima:~ buildbox$ cd /tmp lima:/tmp buildbox$ touch __init__.py lima:/tmp buildbox$ python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import imp >>> imp.find_module("tmp", ['/']) Traceback (most recent call last): File "", line 1, in ? ImportError: No module named tmp >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=809254&group_id=5470 From noreply at sourceforge.net Thu Aug 3 16:14:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 07:14:21 -0700 Subject: [ python-Bugs-1019808 ] wrong socket error returned Message-ID: Bugs item #1019808, was opened at 2004-08-31 12:18 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 Please note that this 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: Federico Schwindt (fgsch) Assigned to: Neal Norwitz (nnorwitz) Summary: wrong socket error returned Initial Comment: hi, first, background: OS: OpenBSD-current/i386 Python version: 2.3.4 example script: import socket socket.setdefaulttimeout(30) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1', 9999)) where nothing is listening on 9999 (ECONNREFUSED should be returned). when ran it i get: Traceback (most recent call last): File "bug.py", line 8, in ? s.connect(('127.0.0.1', 9999)) File "", line 1, in connect socket.error: (22, 'Invalid argument') this is a problem in the socketmodule.c, in the internal_connect() function. getsockopt with SOCK_ERROR should be used once EINPROGRESS is returned to get the real error. this code works on linux, but the connect semantic is, imho, broken. you cannot reuse a socket once it failed (a test afterwards shown that this is valid under linux!!!!). please contact me if you need further details, although i find this very clear. thanks, f.- ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:14 Message: Logged In: YES user_id=11375 I can confirm the bug on MacOS X, and the failure of the patch to fix it. I think the logic of the patch is wrong; it saves errno in save_errno when errno==EINPROGRESS, does a getsockopt(), and then resets errno to save_errno, which we know is EINPROGRESS. I think the correct action is to do 'errno = ". Revised patch attached; it produces the correct result on OS X. ---------------------------------------------------------------------- Comment By: Frank Vercruesse (vercruesse) Date: 2006-02-17 15:46 Message: Logged In: YES user_id=202246 I can confirm the bug running Python 2.4.2 on Mac OS X 10.4.5 (PPC). However, the patch doesn't seem to resolve the issue. Now I get the following traceback when running the posted script: Traceback (most recent call last): File "", line 1, in ? File "", line 1, in connect socket.error: (36, 'Operation now in progress') ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2005-10-03 15:44 Message: Logged In: YES user_id=50493 patch against 2.4.1 appended. not tested in anything but openbsd. nevertheless, i think it should work in linux and osx. not sure about others. cheers. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 02:02 Message: Logged In: YES user_id=33168 Can you provide a patch that you believe corrects this problem? ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2005-06-24 05:41 Message: Logged In: YES user_id=50493 just tried this with 2.4.1 running in OpenBSD 3.7/amd64 and the problem is still there :-( ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2004-09-22 23:58 Message: Logged In: YES user_id=50493 any news? this may be a problem in other *BSDs as well.. ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2004-08-31 12:22 Message: Logged In: YES user_id=50493 maybe i was not clear. the problem is only happening when setdefaulttimeout is used. otherwise ECONNREFUSED is correctly returned. f.- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 From noreply at sourceforge.net Thu Aug 3 16:15:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 07:15:52 -0700 Subject: [ python-Bugs-1019808 ] wrong socket error returned Message-ID: Bugs item #1019808, was opened at 2004-08-31 12:18 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 Please note that this 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: Federico Schwindt (fgsch) Assigned to: Neal Norwitz (nnorwitz) Summary: wrong socket error returned Initial Comment: hi, first, background: OS: OpenBSD-current/i386 Python version: 2.3.4 example script: import socket socket.setdefaulttimeout(30) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1', 9999)) where nothing is listening on 9999 (ECONNREFUSED should be returned). when ran it i get: Traceback (most recent call last): File "bug.py", line 8, in ? s.connect(('127.0.0.1', 9999)) File "", line 1, in connect socket.error: (22, 'Invalid argument') this is a problem in the socketmodule.c, in the internal_connect() function. getsockopt with SOCK_ERROR should be used once EINPROGRESS is returned to get the real error. this code works on linux, but the connect semantic is, imho, broken. you cannot reuse a socket once it failed (a test afterwards shown that this is valid under linux!!!!). please contact me if you need further details, although i find this very clear. thanks, f.- ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:15 Message: Logged In: YES user_id=11375 I can confirm the bug on MacOS X, and the failure of the patch to fix it. I think the logic of the patch is wrong; it saves errno in save_errno when errno==EINPROGRESS, does a getsockopt(), and then resets errno to save_errno, which we know is EINPROGRESS. I think the correct action is to do 'errno = ". Revised patch attached; it produces the correct result on OS X. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:14 Message: Logged In: YES user_id=11375 I can confirm the bug on MacOS X, and the failure of the patch to fix it. I think the logic of the patch is wrong; it saves errno in save_errno when errno==EINPROGRESS, does a getsockopt(), and then resets errno to save_errno, which we know is EINPROGRESS. I think the correct action is to do 'errno = ". Revised patch attached; it produces the correct result on OS X. ---------------------------------------------------------------------- Comment By: Frank Vercruesse (vercruesse) Date: 2006-02-17 15:46 Message: Logged In: YES user_id=202246 I can confirm the bug running Python 2.4.2 on Mac OS X 10.4.5 (PPC). However, the patch doesn't seem to resolve the issue. Now I get the following traceback when running the posted script: Traceback (most recent call last): File "", line 1, in ? File "", line 1, in connect socket.error: (36, 'Operation now in progress') ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2005-10-03 15:44 Message: Logged In: YES user_id=50493 patch against 2.4.1 appended. not tested in anything but openbsd. nevertheless, i think it should work in linux and osx. not sure about others. cheers. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 02:02 Message: Logged In: YES user_id=33168 Can you provide a patch that you believe corrects this problem? ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2005-06-24 05:41 Message: Logged In: YES user_id=50493 just tried this with 2.4.1 running in OpenBSD 3.7/amd64 and the problem is still there :-( ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2004-09-22 23:58 Message: Logged In: YES user_id=50493 any news? this may be a problem in other *BSDs as well.. ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2004-08-31 12:22 Message: Logged In: YES user_id=50493 maybe i was not clear. the problem is only happening when setdefaulttimeout is used. otherwise ECONNREFUSED is correctly returned. f.- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 From noreply at sourceforge.net Thu Aug 3 16:18:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 07:18:02 -0700 Subject: [ python-Bugs-1525343 ] Webserver TypeError: expected read buffer, NoneType found Message-ID: Bugs item #1525343, was opened at 2006-07-19 10:53 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525343&group_id=5470 Please note that this 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: jbet (jbeisert) Assigned to: Nobody/Anonymous (nobody) Summary: Webserver TypeError: expected read buffer, NoneType found Initial Comment: When I'm using the python webserver I got the following message for every access by my client. Soryy, I have no experience in Python, so I cannot help. This is only a report. HTTPdaemon_v1.0.0 listening on port 8001 ---------------------------------------- Exception happened during processing of request from ('192.168.1.9', 33917) Traceback (most recent call last): File "/home/jb/bin/lib/python2.5/SocketServer.py", line 463, in process_request_thread self.finish_request(request, client_address) File "/home/jb/bin/lib/python2.5/SocketServer.py", line 254, in finish_request self.RequestHandlerClass(request, client_address, self) File "/home/jb/bin/lib/python2.5/SocketServer.py", line 521, in __init__ self.handle() File "/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line 316, in handle self.handle_one_request() File "/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line 310, in handle_one_request method() File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 53, in do_GET self.handle_request() File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 56, in handle_request httpreq = HSHTTPRequest(self) File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 254, in __init__ keep_blank_values = True File "/home/jb/bin/lib/python2.5/cgi.py", line 462, in __init__ fp = StringIO(qs) TypeError: expected read buffer, NoneType found ---------------------------------------- ---------------------------------------- Exception happened during processing of request from ('192.168.1.9', 33918) Traceback (most recent call last): File "/home/jb/bin/lib/python2.5/SocketServer.py", line 463, in process_request_thread self.finish_request(request, client_address) File "/home/jb/bin/lib/python2.5/SocketServer.py", line 254, in finish_request self.RequestHandlerClass(request, client_address, self) File "/home/jb/bin/lib/python2.5/SocketServer.py", line 521, in __init__ self.handle() File "/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line 316, in handle self.handle_one_request() File "/home/jb/bin/lib/python2.5/BaseHTTPServer.py", line 310, in handle_one_request method() File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 53, in do_GET self.handle_request() File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 56, in handle_request httpreq = HSHTTPRequest(self) File "./src/Myghty-1.0/lib/myghty/http/HTTPServerHandler.py", line 254, in __init__ keep_blank_values = True File "/home/jb/bin/lib/python2.5/cgi.py", line 462, in __init__ fp = StringIO(qs) TypeError: expected read buffer, NoneType found ---------------------------------------- ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-03 10:18 Message: Logged In: YES user_id=764593 This was a fine place to report it; the question is how to resolve it now that it is reported. The catch is that cgi.py doesn't seem to have changed, and we're not sure it should. ---------------------------------------------------------------------- Comment By: jbet (jbeisert) Date: 2006-08-03 03:39 Message: Logged In: YES user_id=1558389 > Can I ask how you came to use the > as-yet-unreleased Python 2.5 if > you have no experience with Python? We are using Myghty as a webserver, but we have the problem python 2.4 eats up all the memory of the small embedded system. So I tried with python 2.5 with the new memory management...and was stuck at this message. I reported this message to improve 2.5 development. Sorry if this was a wrong way to do it. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-02 18:04 Message: Logged In: YES user_id=764593 I suspect that changing >>> fp = StringIO(qs) to >>> fp = StringIO(qs or "") would fix the problem. If so, this is arguably a bug in myghty. qs was already set to "" unless sys.argv[1] or environ['QUERY_STRING']had a value. Neither of these should ever be None. (They should be either a string, or not found.) ---------------------------------------------------------------------- Comment By: Chad Whitacre (whit537) Date: 2006-08-01 15:04 Message: Logged In: YES user_id=340931 Thanks for the report. Can I ask how you came to use the as-yet-unreleased Python 2.5 if you have no experience with Python? It looks like you are having this problem with Myghty. Does that require Python 2.5? FWIW, this looks to me like a problem with Myghty's use of the cgi module, not a problem with Python itself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1525343&group_id=5470 From noreply at sourceforge.net Thu Aug 3 16:18:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 07:18:50 -0700 Subject: [ python-Bugs-1019808 ] wrong socket error returned Message-ID: Bugs item #1019808, was opened at 2004-08-31 12:18 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 Please note that this 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: Federico Schwindt (fgsch) Assigned to: Neal Norwitz (nnorwitz) Summary: wrong socket error returned Initial Comment: hi, first, background: OS: OpenBSD-current/i386 Python version: 2.3.4 example script: import socket socket.setdefaulttimeout(30) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1', 9999)) where nothing is listening on 9999 (ECONNREFUSED should be returned). when ran it i get: Traceback (most recent call last): File "bug.py", line 8, in ? s.connect(('127.0.0.1', 9999)) File "", line 1, in connect socket.error: (22, 'Invalid argument') this is a problem in the socketmodule.c, in the internal_connect() function. getsockopt with SOCK_ERROR should be used once EINPROGRESS is returned to get the real error. this code works on linux, but the connect semantic is, imho, broken. you cannot reuse a socket once it failed (a test afterwards shown that this is valid under linux!!!!). please contact me if you need further details, although i find this very clear. thanks, f.- ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:18 Message: Logged In: YES user_id=11375 I can confirm the bug on MacOS X, and the failure of the patch to fix it. I think the logic of the patch is wrong; it saves errno in save_errno when errno==EINPROGRESS, does a getsockopt(), and then resets errno to save_errno, which we know is EINPROGRESS. I think the correct action is to do 'errno = ". Revised patch attached; it produces the correct result on OS X. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:15 Message: Logged In: YES user_id=11375 I can confirm the bug on MacOS X, and the failure of the patch to fix it. I think the logic of the patch is wrong; it saves errno in save_errno when errno==EINPROGRESS, does a getsockopt(), and then resets errno to save_errno, which we know is EINPROGRESS. I think the correct action is to do 'errno = ". Revised patch attached; it produces the correct result on OS X. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:14 Message: Logged In: YES user_id=11375 I can confirm the bug on MacOS X, and the failure of the patch to fix it. I think the logic of the patch is wrong; it saves errno in save_errno when errno==EINPROGRESS, does a getsockopt(), and then resets errno to save_errno, which we know is EINPROGRESS. I think the correct action is to do 'errno = ". Revised patch attached; it produces the correct result on OS X. ---------------------------------------------------------------------- Comment By: Frank Vercruesse (vercruesse) Date: 2006-02-17 15:46 Message: Logged In: YES user_id=202246 I can confirm the bug running Python 2.4.2 on Mac OS X 10.4.5 (PPC). However, the patch doesn't seem to resolve the issue. Now I get the following traceback when running the posted script: Traceback (most recent call last): File "", line 1, in ? File "", line 1, in connect socket.error: (36, 'Operation now in progress') ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2005-10-03 15:44 Message: Logged In: YES user_id=50493 patch against 2.4.1 appended. not tested in anything but openbsd. nevertheless, i think it should work in linux and osx. not sure about others. cheers. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 02:02 Message: Logged In: YES user_id=33168 Can you provide a patch that you believe corrects this problem? ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2005-06-24 05:41 Message: Logged In: YES user_id=50493 just tried this with 2.4.1 running in OpenBSD 3.7/amd64 and the problem is still there :-( ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2004-09-22 23:58 Message: Logged In: YES user_id=50493 any news? this may be a problem in other *BSDs as well.. ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2004-08-31 12:22 Message: Logged In: YES user_id=50493 maybe i was not clear. the problem is only happening when setdefaulttimeout is used. otherwise ECONNREFUSED is correctly returned. f.- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 From noreply at sourceforge.net Thu Aug 3 16:31:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 07:31:34 -0700 Subject: [ python-Bugs-1019808 ] wrong socket error returned Message-ID: Bugs item #1019808, was opened at 2004-08-31 12:18 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 Please note that this 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: Federico Schwindt (fgsch) Assigned to: Neal Norwitz (nnorwitz) Summary: wrong socket error returned Initial Comment: hi, first, background: OS: OpenBSD-current/i386 Python version: 2.3.4 example script: import socket socket.setdefaulttimeout(30) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1', 9999)) where nothing is listening on 9999 (ECONNREFUSED should be returned). when ran it i get: Traceback (most recent call last): File "bug.py", line 8, in ? s.connect(('127.0.0.1', 9999)) File "", line 1, in connect socket.error: (22, 'Invalid argument') this is a problem in the socketmodule.c, in the internal_connect() function. getsockopt with SOCK_ERROR should be used once EINPROGRESS is returned to get the real error. this code works on linux, but the connect semantic is, imho, broken. you cannot reuse a socket once it failed (a test afterwards shown that this is valid under linux!!!!). please contact me if you need further details, although i find this very clear. thanks, f.- ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:31 Message: Logged In: YES user_id=11375 Deleting broken patches; attaching a correct version against 2.5 trunk. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:18 Message: Logged In: YES user_id=11375 I can confirm the bug on MacOS X, and the failure of the patch to fix it. I think the logic of the patch is wrong; it saves errno in save_errno when errno==EINPROGRESS, does a getsockopt(), and then resets errno to save_errno, which we know is EINPROGRESS. I think the correct action is to do 'errno = ". Revised patch attached; it produces the correct result on OS X. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:15 Message: Logged In: YES user_id=11375 I can confirm the bug on MacOS X, and the failure of the patch to fix it. I think the logic of the patch is wrong; it saves errno in save_errno when errno==EINPROGRESS, does a getsockopt(), and then resets errno to save_errno, which we know is EINPROGRESS. I think the correct action is to do 'errno = ". Revised patch attached; it produces the correct result on OS X. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:14 Message: Logged In: YES user_id=11375 I can confirm the bug on MacOS X, and the failure of the patch to fix it. I think the logic of the patch is wrong; it saves errno in save_errno when errno==EINPROGRESS, does a getsockopt(), and then resets errno to save_errno, which we know is EINPROGRESS. I think the correct action is to do 'errno = ". Revised patch attached; it produces the correct result on OS X. ---------------------------------------------------------------------- Comment By: Frank Vercruesse (vercruesse) Date: 2006-02-17 15:46 Message: Logged In: YES user_id=202246 I can confirm the bug running Python 2.4.2 on Mac OS X 10.4.5 (PPC). However, the patch doesn't seem to resolve the issue. Now I get the following traceback when running the posted script: Traceback (most recent call last): File "", line 1, in ? File "", line 1, in connect socket.error: (36, 'Operation now in progress') ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2005-10-03 15:44 Message: Logged In: YES user_id=50493 patch against 2.4.1 appended. not tested in anything but openbsd. nevertheless, i think it should work in linux and osx. not sure about others. cheers. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 02:02 Message: Logged In: YES user_id=33168 Can you provide a patch that you believe corrects this problem? ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2005-06-24 05:41 Message: Logged In: YES user_id=50493 just tried this with 2.4.1 running in OpenBSD 3.7/amd64 and the problem is still there :-( ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2004-09-22 23:58 Message: Logged In: YES user_id=50493 any news? this may be a problem in other *BSDs as well.. ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2004-08-31 12:22 Message: Logged In: YES user_id=50493 maybe i was not clear. the problem is only happening when setdefaulttimeout is used. otherwise ECONNREFUSED is correctly returned. f.- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 From noreply at sourceforge.net Thu Aug 3 16:37:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 07:37:26 -0700 Subject: [ python-Bugs-872265 ] fpectl module needs updating Message-ID: Bugs item #872265, was opened at 2004-01-07 05:32 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872265&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Steve Chaplin (stevech) Assigned to: Nobody/Anonymous (nobody) Summary: fpectl module needs updating Initial Comment: The fpectl module docs (Python Library Reference 3.4.2) says "Setting up a given processor to trap IEEE-754 floating point errors currently requires custom code on a per-architecture basis." I think that is no longer accurate, we now have fenv.h, which: - avoids the need for custom code, by using the standard C99 header file - should work on non-Unix and Unix systems I think that the fpectl module could be rewritten and greatly simplified using fenv.h The Python module Numarray has done this and could be used as an example. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:37 Message: Logged In: YES user_id=11375 May as well close this bug; fpectl was a candidate for deletion in 2.5 and may finally go away in 2.6, so no one is going to update it. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-01-17 19:19 Message: Logged In: YES user_id=31435 Note the NEWS file for 2.3 said """ - The fpectl module is not built by default; it's dangerous or useless except in the hands of experts. """ The fpectl module should die. It certainly still requires custom code on a per-*platform* basis regardless, since most C compilers used to build Python predate C99. If we could assume C99 (we can't, just thinking out loud), then a new module offering full access to 754's features should supplant fpectl (fpectl now has a very narrow view of the world). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-01-17 19:03 Message: Logged In: YES user_id=21627 Can you provide a patch? The tricky part is to ensure backwards compatibility if you are fundamentally changing the implementation strategy. Also, what compilers on what architectures support fenv.h? That it is part of C99 does not make it automatically available on all systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=872265&group_id=5470 From noreply at sourceforge.net Thu Aug 3 16:42:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 07:42:25 -0700 Subject: [ python-Bugs-783242 ] test_ossaudiodev timing failure Message-ID: Bugs item #783242, was opened at 2003-08-04 23:14 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783242&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: test_ossaudiodev timing failure Initial Comment: test_audiodev reports a failure because the expected output includes the line: elapsed time: 2.9 sec but when run on my system (RH 9.0), produces the output: elapsed time: 3.0 sec I'm not sure what the right fix is, but including that bit of timing information seems somewhat fragile; you don't want to number to be too low, but it should be ok for it to be a little high since you can't control time slices allocated to the test all that precisely. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:42 Message: Logged In: YES user_id=11375 Duplicate of #1501330, which has been fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=783242&group_id=5470 From noreply at sourceforge.net Thu Aug 3 16:46:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 07:46:25 -0700 Subject: [ python-Bugs-666958 ] repr.repr not always safe Message-ID: Bugs item #666958, was opened at 2003-01-12 23:17 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: repr.repr not always safe Initial Comment: >>> class A: ... def __repr__(self): ... raise Exception ... def someMethod(self): ... pass ... >>> A() Traceback (most recent call last): File "<stdin>", line 1, in ? File "<stdin>", line 3, in __repr__ Exception >>> repr.repr(A()) '<A instance at 237360>' >>> repr.repr(A().someMethod) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.2/repr.py", line 15, in repr return self.repr1(x, self.maxlevel) File "/usr/lib/python2.2/repr.py", line 24, in repr1 s = `x` File "<stdin>", line ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:46 Message: Logged In: YES user_id=11375 Closing as "won't fix", per rhettinger's suggestion. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-03-26 21:50 Message: Logged In: YES user_id=80475 That previous comment should have started with: The behavior of repr.repr(A().someMethod) is the same as __builtin__.repr(A().someMethod) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-03-26 19:01 Message: Logged In: YES user_id=80475 The behavior of repr.repr(A().someMethod) is the same as `repr (A().someMethod)`. Also, in list example provided, a debugger takes you right to the heart of the OP's issue (resolving a faulty user implementation of __repr__). I believe the current behavior both useful and correct. The offered use case is somewhat rare and better solved with pdb. Changing the current behavior would likely impact someone's existing code (doctests for example). Recommend closing this bug. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2004-11-15 19:10 Message: Logged In: YES user_id=752496 What seems like a bug to me is that "repr.repr(A())" and "repr.repr(A().someMethod)" doesn't have the same behaviour. As this still happens in Py2.3.3, I updated the bug metadata. . Facundo ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-02-06 20:33 Message: Logged In: YES user_id=33168 Bob, I'm not sure I understand what you want (ie, what behaviour you desire). If you could provide a patch to the repr module, that could help me. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-02-03 15:27 Message: Logged In: YES user_id=139309 Yes, of course repr.repr is for debugging use.. and it *really* sucks if your debugger crashes! I'm sure that's why it's inconsistent with __builtins__.repr, the bug I'm reporting is that it's inconsistent with itself. Going back to the example of a list again. If you're debugging a list that has one or two items that raise an exception, it's infinitely more useful to know *which* items have a broken __repr__ (along with the context of the valid objects), rather than knowing *one or more* items in the list has a broken __repr__. repr.repr is often called recursively; if something bad happens far down in the call stack it can really be a pain to track down where it happened (all tracebacks to repr are going to look mostly the same) unless repr.repr is fixed to handle this situation. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-21 15:58 Message: Logged In: YES user_id=539787 Sorry, incomplete last post, I clicked in the wrong place (ie SUBMIT) to come back to IE. The case is that repr.py is documented as for debugging use... you suggest that all exceptions are caught, but that would not be consistent with __builtins__.repr . If the module was intended for generic use, I would suggest the opposite; no exceptions should be caught (for consistency). ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-21 15:47 Message: Logged In: YES user_id=539787 Do you suggest to remove the exception catching in Repr.repr_instance or adding a try clause in the s = `x` line of Repr.repr1 ? ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-01-20 09:11 Message: Logged In: YES user_id=139309 It's not my module, it comes with Python (at least in my 2.2, and 2.3 CVS HEAD). Look for yourself! The issue has nothing to do with the fact that it has the same name as the builtin. ---------------------------------------------------------------------- Comment By: Christos Georgiou (tzot) Date: 2003-01-20 00:28 Message: Logged In: YES user_id=539787 Did you try to change the module name to, say, repr2 and then run it again? Any specific reason you named the module as an internal function? BTW, what is repr.repr supposed to do? Please supply the repr.py script, along with the full traceback. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2003-01-13 09:54 Message: Logged In: YES user_id=139309 I say it's a bug because it's inconsistent behavior. You can repr the class instance that throws during a __repr__ just fine ('<A instance at 237360>' ), but you can't __repr__ a bound method of the class instance without throwing an exception. In fact, if the __repr__ of the class instance returns anything but a string, say it returns None for example, then the exception will bubble all the way up and you get no useful output from repr.repr. It's very annoying if you're doing something equivalent to, but more useful than: repr.repr([1, 2, 3, 4, A().someMethod, 6, 7, 8, A()]) Note that repr.repr([1, 2, 3, 4, A(), 6, 7, 8]) does not throw any exceptions. There should be some sort of graceful way to do it, no? I think it ought to handle the bound method broken instance case just like it handles the broken instance case directly. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-01-12 23:34 Message: Logged In: YES user_id=31435 Why do say this is a bug? If you raise an exception, yes, you get an exception. Most __repr__ *implementations* try hard not to raise any exceptions, but it's never guaranteed that they won't. For example, just about any __repr__ implementation may run out of memory while trying to build its result string, so MemoryError is almost always a possible exception. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=666958&group_id=5470 From noreply at sourceforge.net Thu Aug 3 17:04:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 08:04:23 -0700 Subject: [ python-Bugs-995458 ] Does not build selected SGI specific modules Message-ID: Bugs item #995458, was opened at 2004-07-21 14:55 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995458&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Bruce D. Ray (brucedray) Assigned to: Nobody/Anonymous (nobody) Summary: Does not build selected SGI specific modules Initial Comment: System is SGI R10K running Irix 6.5.15 Compiler is MIPSpro 7.3 Default configuration build sequence works and installs a python 2.3.4 that does not support GL, audio, etc. because the SGI specific modules for those are not built in the default configuration. To quote the README: On SGI IRIX, there are modules that interface to many SGI specific system libraries, e.g. the GL library and the audio hardware. These modules will not be built by the setup.py script. Therefore, after the default configuration build and install, I uncommented the lines in Modules/Setup that read: gl glmodule.c cgensupport.c -I$(srcdir) $(GLHACK) -lgl -lX11 fm fmmodule.c $(GLHACK) -lfm -lgl sgi sgimodule.c al almodule.c -laudio cd cdmodule.c -lcdaudio -lds -lmediad cl clmodule.c -lcl -lawareaudio fpectl fpectlmodule.c -lfpe fpetest fpetestmodule.c I then did a make clean followed by make Errors returned were: cc -o python \ Modules/python.o \ libpython2.3.a -ldl -lpthread -lmpc -lm ld32: WARNING 84 : /usr/lib32/libdl.so is not used for resolving any symbol. ld32: WARNING 84 : /usr/lib32/mips4/libmpc.a is not used for resolving any symbol. ld32: ERROR 33 : Unresolved text symbol "initgl" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "initfm" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "initsgi" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "inital" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "initcd" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "initcl" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "initfpectl" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: ERROR 33 : Unresolved text symbol "initfpetest" -- 1st referenced by libpython2.3.a(config.o). Use linker option -v to see when and which objects, archives and dsos are loaded. ld32: INFO 152: Output file removed because of error. *** Error code 2 (bu21) A previous message on the build said that I would have to rerun make Therefore, I again did a make clean followed by make and got the error message: don't know how to make glmodule.c How is this build to be done? ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 11:04 Message: Logged In: YES user_id=11375 The makesetup script special-cases the glmodule.c file (around line 214); this is responsible for "don't know how to make glmodule.c". Presumably at one point the glmodule.c file would always be regenerated. I still have no idea why linking fails. ---------------------------------------------------------------------- Comment By: Bruce D. Ray (brucedray) Date: 2004-08-09 09:00 Message: Logged In: YES user_id=1063363 I believe I have listed a bug in the build and what would appear to be a problem in documentation as well. These are: 1. When the lines listed previously in Modules/Setup for SGI specific modules are uncommented, there appears to be a problem in the construction of the Makefile that points the build away from the SGI specific modules to be built. The result of this is a total failure to build python 2.3.4 with SGI specific modules with error messages as given previously. 2. Documentation on the general issue of use of Modules/Setup to build modules not otherwise built is not adequate. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-08-07 13:55 Message: Logged In: YES user_id=11375 So what exactly is the bug? ---------------------------------------------------------------------- Comment By: Bruce D. Ray (brucedray) Date: 2004-07-30 10:00 Message: Logged In: YES user_id=1063363 Would that be something like the message () I posted to comp.lang.python 15 Jul. 2004? I posted that back before I managed to tease out of the various convolutions of the build hints that there might be a problem in the construction of a Makefile that points the build to the wrong directory. As hinted at in that article, I had already done a search of the publicly available documentation on python (actually several searches including a download and grep of these). I also did searches of comp.lang.python for anything related to SGI, Silicon Graphics, or Irix; and of comp.sys.sgi.* for anything related to python (if you wish to reproduce this, you might want to exclude the strings "dat" and "tape" because of the many queries there on how to use a Python brand drive for archiving). By 21 Jul. 2004, when I opened this, I was persuaded that I have found a bug in the build, or at least a deficiency in the documentation for build and install. I believe that I have found a bug in the distribution with respect to building on SGI with MIPSpro 7.3 compilers a python with support for available SGI functionality. Thank-you kindly for your reply, but I really am reporting what appears to be a bug. Accordingly, I will leave this open. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2004-07-29 19:14 Message: Logged In: YES user_id=593130 The appropriate place for how-to questions is comp.lang.python and the corresponding mailing list. Please consider closing this until you are fairly sure you have found a bug in the distribution itself. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=995458&group_id=5470 From noreply at sourceforge.net Thu Aug 3 18:43:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 09:43:43 -0700 Subject: [ python-Bugs-1524938 ] PEP MemoryError with a lot of available memory gc not called Message-ID: Bugs item #1524938, was opened at 2006-07-19 04:46 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470 Please note that this 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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Mark Matusevich (markmat) Assigned to: Nobody/Anonymous (nobody) Summary: PEP MemoryError with a lot of available memory gc not called Initial Comment: Also the gc behavior is consistent with the documentation, I beleave it is wrong. I think, that Gc should be called automatically before any memory allocation is raised. Example 1: for i in range(700): a = [range(5000000)] a.append(a) print i This example will crash on any any PC with less then 20Gb RAM. On my PC (Windows 2000, 256Mb) it crashes at i==7. Also, this example can be fixed by addition of a call to gc.collect() in the loop, in real cases it may be unreasonable. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-03 18:43 Message: Logged In: YES user_id=21627 The example is highly constructed, and it is pointless to optimize for a boundary case. In the average application, garbage collection is invoked often enough to reclaim memory before swapping occurs. ---------------------------------------------------------------------- Comment By: Mark Matusevich (markmat) Date: 2006-08-03 12:02 Message: Logged In: YES user_id=1337765 Another problem related to the above example: there is a time waste due to a memory swap before the MemoryError. Possible solution is to use a dynamic memory limit: GC is called when the limit is reached, then the limit is adjusted according to the memory left. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-02 23:52 Message: Logged In: YES user_id=764593 Doing it everywhere would be a lot of painful changes. Adding the "oops, failed, call gc and try again" to to PyMem_* (currently PyMem_Malloc, PyMem_Realloc, PyMem_New, and PyMem_Resize, but Brett may be changing that) is far more reasonable. Whether it is safe to call gc from there is a different question. ---------------------------------------------------------------------- Comment By: Mark Matusevich (markmat) Date: 2006-07-23 22:19 Message: Logged In: YES user_id=1337765 Sorry, my last comment was to illume (I am slow typer :( ) ---------------------------------------------------------------------- Comment By: Mark Matusevich (markmat) Date: 2006-07-23 22:11 Message: Logged In: YES user_id=1337765 This is exectly what I meant. For my recollection, this is the policy in Java GC. I never had to handle MemoryError in Java, because I knew, that I really do not have any more memory. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-07-23 22:00 Message: Logged In: YES user_id=21627 This is very difficult to implement. The best way might be to introduce yet another allocation function, one that invokes gc before failing, and call that function in all interesting places (of which there are many). Contributions are welcome and should probably start with a PEP first. ---------------------------------------------------------------------- Comment By: Rene Dudfield (illume) Date: 2006-07-20 01:20 Message: Logged In: YES user_id=2042 Perhaps better than checking before every memory allocation, would be to check once a memory error happens in an allocation. That way there is only the gc hit once there is low memory. So... res = malloc(...); if(!res) { gc.collect(); } res = malloc(...); if(!res) { raise memory error. } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1524938&group_id=5470 From noreply at sourceforge.net Thu Aug 3 19:23:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 10:23:13 -0700 Subject: [ python-Bugs-1534014 ] __name__ doesn't show up in dir() of class Message-ID: Bugs item #1534014, was opened at 2006-08-03 12:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534014&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Type/class unification Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Tim Chase (gumnos) Assigned to: Nobody/Anonymous (nobody) Summary: __name__ doesn't show up in dir() of class Initial Comment: The __name__ attribute doesn't appear in the dir() of a class, yet is an available attribute. The below reproduces the problem: >>> class Foo(object): pass >>> dir(Foo) ['__class__', '__delattr__', '__dict__', '__doc__', '__getattribute__', '__hash__', '__init__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', '__weakref__'] >>> Foo.__name__ 'Foo' Note that this is different from the attribute appearing in an *instance* of the class, as in >>> x = Foo() >>> '__name__' in dir(x) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534014&group_id=5470 From noreply at sourceforge.net Thu Aug 3 19:30:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 10:30:48 -0700 Subject: [ python-Bugs-1534014 ] __name__ doesn't show up in dir() of class Message-ID: Bugs item #1534014, was opened at 2006-08-03 12:23 Message generated for change (Settings changed) made by gumnos You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534014&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Type/class unification Group: Python 2.4 Status: Open Resolution: None >Priority: 4 Submitted By: Tim Chase (gumnos) Assigned to: Nobody/Anonymous (nobody) Summary: __name__ doesn't show up in dir() of class Initial Comment: The __name__ attribute doesn't appear in the dir() of a class, yet is an available attribute. The below reproduces the problem: >>> class Foo(object): pass >>> dir(Foo) ['__class__', '__delattr__', '__dict__', '__doc__', '__getattribute__', '__hash__', '__init__', '__module__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', '__weakref__'] >>> Foo.__name__ 'Foo' Note that this is different from the attribute appearing in an *instance* of the class, as in >>> x = Foo() >>> '__name__' in dir(x) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534014&group_id=5470 From noreply at sourceforge.net Thu Aug 3 21:24:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 12:24:51 -0700 Subject: [ python-Bugs-1530448 ] ctypes build fails on Solaris 10 Message-ID: Bugs item #1530448, was opened at 2006-07-28 17:04 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-08-03 21:24 Message: Logged In: YES user_id=11105 What I've found out, after some painful time on the sourceforge compilefarm, is this: Python svn trunk also fails to build _ctypes.so on the solaris-x86 machine, but not on the sparc machines (both have solaris 9, I believe). ctypes from svn trunk *does* build also on the x86 machine, with the system installed python2.3, also with python 2.5b2. One difference that I found is that ctypes svn setup.py passes '-impure-text' to the linker, while python svn (when building the bundled ctypes) does not. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-02 15:20 Message: Logged In: YES user_id=11105 It seems that the files 'src/x86/ffi.c' and 'src/x86/sysv.S' are not needed for the X86_64 platform in fficonfig.py.in. They *should* compile to nothing, anyway, because their contents is protected by 'ifndef __x86_64__'. Does removing them from fficonfig.py.in change the situation, so that only this remains: 'X86_64': ['src/x86/ffi64.c', 'src/x86/unix64.S'], I can build _ctypes on an unbuntu amd64 system with this change. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-02 15:08 Message: Logged In: YES user_id=44345 I don't understand. I swapped the order of ffi.c and sysv.S in the platforms dict. I confirmed that the order of the .o files on the link line changed so that ffi.o followed sysv.o. I still get the same error. I've also confirmed that ffi.o exports the symbol and that sysv.o references it: % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 U _GLOBAL_OFFSET_TABLE_ 0000000000 f ffi.c 0000000332 T ffi_call 0000000000 U ffi_call_SYSV 0000000000 U ffi_closure_SYSV 0000000456 T ffi_closure_SYSV_inner 0000000000 T ffi_prep_args 0000000252 T ffi_prep_cif_machdep 0000000612 T ffi_prep_closure 0000000000 U memcpy % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000109 n epilogue 0000000000 T ffi_call_SYSV 0000000116 T ffi_closure_SYSV 0000000000 U ffi_closure_SYSV_inner 0000000000 U ffi_prep_args 0000000109 n noretval 0000000071 n retdouble 0000000059 n retfloat 0000000046 n retint 0000000095 n retint64 0000000083 n retlongdouble 0000000109 n retstruct All the object files were compiled with -fPIC. Here's the relevant chunk of make's output: creating build/temp.solaris-2.10-i86pc-2.5/libffi checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for gcc... /opt/app/g++lib6/gcc-3.4/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /opt/app/g++lib6/gcc-3.4/bin/gcc accepts -g... yes checking for /opt/app/g++lib6/gcc-3.4/bin/gcc option to accept ANSI C... none needed checking how to run the C preprocessor... /opt/app/g++lib6/gcc-3.4/bin/gcc -E checking for egrep... egrep checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking sys/mman.h usability... yes checking sys/mman.h presence... yes checking for sys/mman.h... yes checking for mmap... yes checking for sys/mman.h... (cached) yes checking for mmap... (cached) yes checking whether read-only mmap of a plain file works... yes checking whether mmap from /dev/zero works... yes checking for MAP_ANON(YMOUS)... yes checking whether mmap with MAP_ANON(YMOUS) works... yes checking for ANSI C header files... (cached) yes checking for memcpy... yes checking for working alloca.h... yes checking for alloca... yes checking for double... yes checking size of double... 8 checking for long double... yes checking size of long double... 12 checking whether byte ordering is bigendian... no checking whether .eh_frame section should be read-only... no checking for __attribute__((visibility("hidden")))... no configure: creating ./config.status config.status: creating include/ffi.h config.status: creating fficonfig.py config.status: creating fficonfig.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffitarget.h to include/ffitarget.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/include/ffi_common.h to include/ffi_common.h config.status: executing include commands config.status: executing src commands >>> X86_64 ['src/prep_cif.c', 'src/x86/ffi64.c', 'src/x86/unix64.S', 'src/x86/sysv.S', 'src/x86/ffi.c'] building '_ctypes' extension /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c: In function `_CallProc': /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c:917: warning: implicit declaration of function `alloca' /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:177: warning: function declaration isn't a prototype /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:194: warning: function declaration isn't a prototype /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I added a couple prints to fficonfig.py.in to demonstrate the file order and platform name (and to make sure fficonfig.py was being rebuilt). Oddly enough, if I remove both ffi.o and sysv.o from the link line, it links successfully. Is that significant or am I just getting desparate? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-01 22:02 Message: Logged In: YES user_id=11105 I didn't know there are any systems that depend on the order of object files on the linker command line any more ;-). IIUC, the objects list is derived by distutils from the sources list, so the attached patch (for Modules/_ctypes/libffi/fficonfig.py.in) *could* do the trick. Please make sure that fficonfig.py is recreated (by doing make clean before building or whatever). Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-01 18:16 Message: Logged In: YES user_id=44345 Thomas> Skip, do you have *any* idea what might be Thomas> wrong, or could you even come up with a patch? Skip> I've no idea so far. I'll try to find some time Skip> to take a look at it later today. Thomas, Sorry for the delay. I think I have it figured out and it was fairly straightforward. Looking at the files in order on the _ctypes.so link line we see that the definition of ffi_closure_SYSV_inner is defined before it's referenced: for obj in build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ; do echo $obj; nm -p $obj | egrep ffi_closure_SYSV_inner; done build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o 0000000456 T ffi_closure_SYSV_inner build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o 0000000000 U ffi_closure_SYSV_inner Since we're linking from object files, it's a one-pass link algorithm. At the time ffo.o is examined, sysv.o hasn't been seen. Consequently, ffi_closure_SYSV_inner is not yet known and its definition isn't picked up from ffi.o. I couldn't quickly figure out where the link command is generated, but I'm sure you'll know where it resides. Either swap ffi.o and sysv.o on the link line, or add ffi.o a second time to resolve the new reference. Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-31 12:54 Message: Logged In: YES user_id=11105 Skip, do you have *any* idea what might be wrong, or could you even come up with a patch? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-07-29 00:03 Message: Logged In: YES user_id=44345 Yeah, you'd definitely need -fPIC on any brand of Solaris. That test might be changed to plat = get_platform() if plat in (... buncha platforms ...) or "solaris" in plat: os.environ["CFLAGS"] = "-fPIC" That doesn't seem to be what's happening in this case though. I rm'd the .o files in .../Modules/_ctypes and tried again. The compile commands *do* have -fPIC on them. I don't think it's required on the link line. S ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-28 18:19 Message: Logged In: YES user_id=11105 Skip, This looks *somewhat* like the problems reported in bugs 1529269 and 1528620 (although they have a sparc, and you seem to have x86 solaris). Hm, in the standalone ctypes setup script, I find this code snippet: if get_platform() in ["solaris-2.9-sun4u", "linux-x86_64"]: os.environ["CFLAGS"] = "-fPIC" Can it be that -fPIC must be used, but is not specified? It is also funny that the solaris buildbot does NOT seem to have a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 From noreply at sourceforge.net Thu Aug 3 21:28:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 12:28:07 -0700 Subject: [ python-Bugs-1530448 ] ctypes build fails on Solaris 10 Message-ID: Bugs item #1530448, was opened at 2006-07-28 17:04 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-08-03 21:28 Message: Logged In: YES user_id=11105 And, BTW, building the bz2 extension on the compile farm solaris-x86 machine also fails with relocation errors (but I have no idea if that is related to the _ctypes build failure or not). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 21:24 Message: Logged In: YES user_id=11105 What I've found out, after some painful time on the sourceforge compilefarm, is this: Python svn trunk also fails to build _ctypes.so on the solaris-x86 machine, but not on the sparc machines (both have solaris 9, I believe). ctypes from svn trunk *does* build also on the x86 machine, with the system installed python2.3, also with python 2.5b2. One difference that I found is that ctypes svn setup.py passes '-impure-text' to the linker, while python svn (when building the bundled ctypes) does not. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-02 15:20 Message: Logged In: YES user_id=11105 It seems that the files 'src/x86/ffi.c' and 'src/x86/sysv.S' are not needed for the X86_64 platform in fficonfig.py.in. They *should* compile to nothing, anyway, because their contents is protected by 'ifndef __x86_64__'. Does removing them from fficonfig.py.in change the situation, so that only this remains: 'X86_64': ['src/x86/ffi64.c', 'src/x86/unix64.S'], I can build _ctypes on an unbuntu amd64 system with this change. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-02 15:08 Message: Logged In: YES user_id=44345 I don't understand. I swapped the order of ffi.c and sysv.S in the platforms dict. I confirmed that the order of the .o files on the link line changed so that ffi.o followed sysv.o. I still get the same error. I've also confirmed that ffi.o exports the symbol and that sysv.o references it: % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 U _GLOBAL_OFFSET_TABLE_ 0000000000 f ffi.c 0000000332 T ffi_call 0000000000 U ffi_call_SYSV 0000000000 U ffi_closure_SYSV 0000000456 T ffi_closure_SYSV_inner 0000000000 T ffi_prep_args 0000000252 T ffi_prep_cif_machdep 0000000612 T ffi_prep_closure 0000000000 U memcpy % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000109 n epilogue 0000000000 T ffi_call_SYSV 0000000116 T ffi_closure_SYSV 0000000000 U ffi_closure_SYSV_inner 0000000000 U ffi_prep_args 0000000109 n noretval 0000000071 n retdouble 0000000059 n retfloat 0000000046 n retint 0000000095 n retint64 0000000083 n retlongdouble 0000000109 n retstruct All the object files were compiled with -fPIC. Here's the relevant chunk of make's output: creating build/temp.solaris-2.10-i86pc-2.5/libffi checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for gcc... /opt/app/g++lib6/gcc-3.4/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /opt/app/g++lib6/gcc-3.4/bin/gcc accepts -g... yes checking for /opt/app/g++lib6/gcc-3.4/bin/gcc option to accept ANSI C... none needed checking how to run the C preprocessor... /opt/app/g++lib6/gcc-3.4/bin/gcc -E checking for egrep... egrep checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking sys/mman.h usability... yes checking sys/mman.h presence... yes checking for sys/mman.h... yes checking for mmap... yes checking for sys/mman.h... (cached) yes checking for mmap... (cached) yes checking whether read-only mmap of a plain file works... yes checking whether mmap from /dev/zero works... yes checking for MAP_ANON(YMOUS)... yes checking whether mmap with MAP_ANON(YMOUS) works... yes checking for ANSI C header files... (cached) yes checking for memcpy... yes checking for working alloca.h... yes checking for alloca... yes checking for double... yes checking size of double... 8 checking for long double... yes checking size of long double... 12 checking whether byte ordering is bigendian... no checking whether .eh_frame section should be read-only... no checking for __attribute__((visibility("hidden")))... no configure: creating ./config.status config.status: creating include/ffi.h config.status: creating fficonfig.py config.status: creating fficonfig.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffitarget.h to include/ffitarget.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/include/ffi_common.h to include/ffi_common.h config.status: executing include commands config.status: executing src commands >>> X86_64 ['src/prep_cif.c', 'src/x86/ffi64.c', 'src/x86/unix64.S', 'src/x86/sysv.S', 'src/x86/ffi.c'] building '_ctypes' extension /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c: In function `_CallProc': /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c:917: warning: implicit declaration of function `alloca' /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:177: warning: function declaration isn't a prototype /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:194: warning: function declaration isn't a prototype /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I added a couple prints to fficonfig.py.in to demonstrate the file order and platform name (and to make sure fficonfig.py was being rebuilt). Oddly enough, if I remove both ffi.o and sysv.o from the link line, it links successfully. Is that significant or am I just getting desparate? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-01 22:02 Message: Logged In: YES user_id=11105 I didn't know there are any systems that depend on the order of object files on the linker command line any more ;-). IIUC, the objects list is derived by distutils from the sources list, so the attached patch (for Modules/_ctypes/libffi/fficonfig.py.in) *could* do the trick. Please make sure that fficonfig.py is recreated (by doing make clean before building or whatever). Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-01 18:16 Message: Logged In: YES user_id=44345 Thomas> Skip, do you have *any* idea what might be Thomas> wrong, or could you even come up with a patch? Skip> I've no idea so far. I'll try to find some time Skip> to take a look at it later today. Thomas, Sorry for the delay. I think I have it figured out and it was fairly straightforward. Looking at the files in order on the _ctypes.so link line we see that the definition of ffi_closure_SYSV_inner is defined before it's referenced: for obj in build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ; do echo $obj; nm -p $obj | egrep ffi_closure_SYSV_inner; done build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o 0000000456 T ffi_closure_SYSV_inner build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o 0000000000 U ffi_closure_SYSV_inner Since we're linking from object files, it's a one-pass link algorithm. At the time ffo.o is examined, sysv.o hasn't been seen. Consequently, ffi_closure_SYSV_inner is not yet known and its definition isn't picked up from ffi.o. I couldn't quickly figure out where the link command is generated, but I'm sure you'll know where it resides. Either swap ffi.o and sysv.o on the link line, or add ffi.o a second time to resolve the new reference. Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-31 12:54 Message: Logged In: YES user_id=11105 Skip, do you have *any* idea what might be wrong, or could you even come up with a patch? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-07-29 00:03 Message: Logged In: YES user_id=44345 Yeah, you'd definitely need -fPIC on any brand of Solaris. That test might be changed to plat = get_platform() if plat in (... buncha platforms ...) or "solaris" in plat: os.environ["CFLAGS"] = "-fPIC" That doesn't seem to be what's happening in this case though. I rm'd the .o files in .../Modules/_ctypes and tried again. The compile commands *do* have -fPIC on them. I don't think it's required on the link line. S ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-28 18:19 Message: Logged In: YES user_id=11105 Skip, This looks *somewhat* like the problems reported in bugs 1529269 and 1528620 (although they have a sparc, and you seem to have x86 solaris). Hm, in the standalone ctypes setup script, I find this code snippet: if get_platform() in ["solaris-2.9-sun4u", "linux-x86_64"]: os.environ["CFLAGS"] = "-fPIC" Can it be that -fPIC must be used, but is not specified? It is also funny that the solaris buildbot does NOT seem to have a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 From noreply at sourceforge.net Thu Aug 3 21:36:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 12:36:39 -0700 Subject: [ python-Bugs-1530448 ] ctypes build fails on Solaris 10 Message-ID: Bugs item #1530448, was opened at 2006-07-28 17:04 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-08-03 21:36 Message: Logged In: YES user_id=11105 Correction: The option is '-mimpure-text', not '-impure-text'. I've attached a new patch 'setup.py.patch' which allows to build on the sourceforge solaris-x86 machine. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 21:28 Message: Logged In: YES user_id=11105 And, BTW, building the bz2 extension on the compile farm solaris-x86 machine also fails with relocation errors (but I have no idea if that is related to the _ctypes build failure or not). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 21:24 Message: Logged In: YES user_id=11105 What I've found out, after some painful time on the sourceforge compilefarm, is this: Python svn trunk also fails to build _ctypes.so on the solaris-x86 machine, but not on the sparc machines (both have solaris 9, I believe). ctypes from svn trunk *does* build also on the x86 machine, with the system installed python2.3, also with python 2.5b2. One difference that I found is that ctypes svn setup.py passes '-impure-text' to the linker, while python svn (when building the bundled ctypes) does not. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-02 15:20 Message: Logged In: YES user_id=11105 It seems that the files 'src/x86/ffi.c' and 'src/x86/sysv.S' are not needed for the X86_64 platform in fficonfig.py.in. They *should* compile to nothing, anyway, because their contents is protected by 'ifndef __x86_64__'. Does removing them from fficonfig.py.in change the situation, so that only this remains: 'X86_64': ['src/x86/ffi64.c', 'src/x86/unix64.S'], I can build _ctypes on an unbuntu amd64 system with this change. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-02 15:08 Message: Logged In: YES user_id=44345 I don't understand. I swapped the order of ffi.c and sysv.S in the platforms dict. I confirmed that the order of the .o files on the link line changed so that ffi.o followed sysv.o. I still get the same error. I've also confirmed that ffi.o exports the symbol and that sysv.o references it: % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 U _GLOBAL_OFFSET_TABLE_ 0000000000 f ffi.c 0000000332 T ffi_call 0000000000 U ffi_call_SYSV 0000000000 U ffi_closure_SYSV 0000000456 T ffi_closure_SYSV_inner 0000000000 T ffi_prep_args 0000000252 T ffi_prep_cif_machdep 0000000612 T ffi_prep_closure 0000000000 U memcpy % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000109 n epilogue 0000000000 T ffi_call_SYSV 0000000116 T ffi_closure_SYSV 0000000000 U ffi_closure_SYSV_inner 0000000000 U ffi_prep_args 0000000109 n noretval 0000000071 n retdouble 0000000059 n retfloat 0000000046 n retint 0000000095 n retint64 0000000083 n retlongdouble 0000000109 n retstruct All the object files were compiled with -fPIC. Here's the relevant chunk of make's output: creating build/temp.solaris-2.10-i86pc-2.5/libffi checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for gcc... /opt/app/g++lib6/gcc-3.4/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /opt/app/g++lib6/gcc-3.4/bin/gcc accepts -g... yes checking for /opt/app/g++lib6/gcc-3.4/bin/gcc option to accept ANSI C... none needed checking how to run the C preprocessor... /opt/app/g++lib6/gcc-3.4/bin/gcc -E checking for egrep... egrep checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking sys/mman.h usability... yes checking sys/mman.h presence... yes checking for sys/mman.h... yes checking for mmap... yes checking for sys/mman.h... (cached) yes checking for mmap... (cached) yes checking whether read-only mmap of a plain file works... yes checking whether mmap from /dev/zero works... yes checking for MAP_ANON(YMOUS)... yes checking whether mmap with MAP_ANON(YMOUS) works... yes checking for ANSI C header files... (cached) yes checking for memcpy... yes checking for working alloca.h... yes checking for alloca... yes checking for double... yes checking size of double... 8 checking for long double... yes checking size of long double... 12 checking whether byte ordering is bigendian... no checking whether .eh_frame section should be read-only... no checking for __attribute__((visibility("hidden")))... no configure: creating ./config.status config.status: creating include/ffi.h config.status: creating fficonfig.py config.status: creating fficonfig.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffitarget.h to include/ffitarget.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/include/ffi_common.h to include/ffi_common.h config.status: executing include commands config.status: executing src commands >>> X86_64 ['src/prep_cif.c', 'src/x86/ffi64.c', 'src/x86/unix64.S', 'src/x86/sysv.S', 'src/x86/ffi.c'] building '_ctypes' extension /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c: In function `_CallProc': /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c:917: warning: implicit declaration of function `alloca' /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:177: warning: function declaration isn't a prototype /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:194: warning: function declaration isn't a prototype /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I added a couple prints to fficonfig.py.in to demonstrate the file order and platform name (and to make sure fficonfig.py was being rebuilt). Oddly enough, if I remove both ffi.o and sysv.o from the link line, it links successfully. Is that significant or am I just getting desparate? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-01 22:02 Message: Logged In: YES user_id=11105 I didn't know there are any systems that depend on the order of object files on the linker command line any more ;-). IIUC, the objects list is derived by distutils from the sources list, so the attached patch (for Modules/_ctypes/libffi/fficonfig.py.in) *could* do the trick. Please make sure that fficonfig.py is recreated (by doing make clean before building or whatever). Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-01 18:16 Message: Logged In: YES user_id=44345 Thomas> Skip, do you have *any* idea what might be Thomas> wrong, or could you even come up with a patch? Skip> I've no idea so far. I'll try to find some time Skip> to take a look at it later today. Thomas, Sorry for the delay. I think I have it figured out and it was fairly straightforward. Looking at the files in order on the _ctypes.so link line we see that the definition of ffi_closure_SYSV_inner is defined before it's referenced: for obj in build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ; do echo $obj; nm -p $obj | egrep ffi_closure_SYSV_inner; done build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o 0000000456 T ffi_closure_SYSV_inner build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o 0000000000 U ffi_closure_SYSV_inner Since we're linking from object files, it's a one-pass link algorithm. At the time ffo.o is examined, sysv.o hasn't been seen. Consequently, ffi_closure_SYSV_inner is not yet known and its definition isn't picked up from ffi.o. I couldn't quickly figure out where the link command is generated, but I'm sure you'll know where it resides. Either swap ffi.o and sysv.o on the link line, or add ffi.o a second time to resolve the new reference. Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-31 12:54 Message: Logged In: YES user_id=11105 Skip, do you have *any* idea what might be wrong, or could you even come up with a patch? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-07-29 00:03 Message: Logged In: YES user_id=44345 Yeah, you'd definitely need -fPIC on any brand of Solaris. That test might be changed to plat = get_platform() if plat in (... buncha platforms ...) or "solaris" in plat: os.environ["CFLAGS"] = "-fPIC" That doesn't seem to be what's happening in this case though. I rm'd the .o files in .../Modules/_ctypes and tried again. The compile commands *do* have -fPIC on them. I don't think it's required on the link line. S ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-28 18:19 Message: Logged In: YES user_id=11105 Skip, This looks *somewhat* like the problems reported in bugs 1529269 and 1528620 (although they have a sparc, and you seem to have x86 solaris). Hm, in the standalone ctypes setup script, I find this code snippet: if get_platform() in ["solaris-2.9-sun4u", "linux-x86_64"]: os.environ["CFLAGS"] = "-fPIC" Can it be that -fPIC must be used, but is not specified? It is also funny that the solaris buildbot does NOT seem to have a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 From noreply at sourceforge.net Thu Aug 3 22:02:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 13:02:07 -0700 Subject: [ python-Bugs-1530448 ] ctypes build fails on Solaris 10 Message-ID: Bugs item #1530448, was opened at 2006-07-28 10:04 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 15:02 Message: Logged In: YES user_id=44345 Thomas, I did an svn up (rev 51078), deleted any local changes, created a new build directory, configured and built. I got the same error about ffi_closure_SYSV_inner. I then manually reran the link command without mention of ffi.o or sysv.o. It linked fine but when I ran make again it complained that _ctypes.so couldn't resolve ffi_prep_closure. This symbol is defined in ffi.o, so it appears either that ffi.c is needed in the source list or maybe ffi64.c needs to be modified to provide it. As far as I can tell it doesn't export any useful symbols: $ nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 f ffi64.c Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 14:36 Message: Logged In: YES user_id=11105 Correction: The option is '-mimpure-text', not '-impure-text'. I've attached a new patch 'setup.py.patch' which allows to build on the sourceforge solaris-x86 machine. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 14:28 Message: Logged In: YES user_id=11105 And, BTW, building the bz2 extension on the compile farm solaris-x86 machine also fails with relocation errors (but I have no idea if that is related to the _ctypes build failure or not). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 14:24 Message: Logged In: YES user_id=11105 What I've found out, after some painful time on the sourceforge compilefarm, is this: Python svn trunk also fails to build _ctypes.so on the solaris-x86 machine, but not on the sparc machines (both have solaris 9, I believe). ctypes from svn trunk *does* build also on the x86 machine, with the system installed python2.3, also with python 2.5b2. One difference that I found is that ctypes svn setup.py passes '-impure-text' to the linker, while python svn (when building the bundled ctypes) does not. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-02 08:20 Message: Logged In: YES user_id=11105 It seems that the files 'src/x86/ffi.c' and 'src/x86/sysv.S' are not needed for the X86_64 platform in fficonfig.py.in. They *should* compile to nothing, anyway, because their contents is protected by 'ifndef __x86_64__'. Does removing them from fficonfig.py.in change the situation, so that only this remains: 'X86_64': ['src/x86/ffi64.c', 'src/x86/unix64.S'], I can build _ctypes on an unbuntu amd64 system with this change. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-02 08:08 Message: Logged In: YES user_id=44345 I don't understand. I swapped the order of ffi.c and sysv.S in the platforms dict. I confirmed that the order of the .o files on the link line changed so that ffi.o followed sysv.o. I still get the same error. I've also confirmed that ffi.o exports the symbol and that sysv.o references it: % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 U _GLOBAL_OFFSET_TABLE_ 0000000000 f ffi.c 0000000332 T ffi_call 0000000000 U ffi_call_SYSV 0000000000 U ffi_closure_SYSV 0000000456 T ffi_closure_SYSV_inner 0000000000 T ffi_prep_args 0000000252 T ffi_prep_cif_machdep 0000000612 T ffi_prep_closure 0000000000 U memcpy % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000109 n epilogue 0000000000 T ffi_call_SYSV 0000000116 T ffi_closure_SYSV 0000000000 U ffi_closure_SYSV_inner 0000000000 U ffi_prep_args 0000000109 n noretval 0000000071 n retdouble 0000000059 n retfloat 0000000046 n retint 0000000095 n retint64 0000000083 n retlongdouble 0000000109 n retstruct All the object files were compiled with -fPIC. Here's the relevant chunk of make's output: creating build/temp.solaris-2.10-i86pc-2.5/libffi checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for gcc... /opt/app/g++lib6/gcc-3.4/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /opt/app/g++lib6/gcc-3.4/bin/gcc accepts -g... yes checking for /opt/app/g++lib6/gcc-3.4/bin/gcc option to accept ANSI C... none needed checking how to run the C preprocessor... /opt/app/g++lib6/gcc-3.4/bin/gcc -E checking for egrep... egrep checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking sys/mman.h usability... yes checking sys/mman.h presence... yes checking for sys/mman.h... yes checking for mmap... yes checking for sys/mman.h... (cached) yes checking for mmap... (cached) yes checking whether read-only mmap of a plain file works... yes checking whether mmap from /dev/zero works... yes checking for MAP_ANON(YMOUS)... yes checking whether mmap with MAP_ANON(YMOUS) works... yes checking for ANSI C header files... (cached) yes checking for memcpy... yes checking for working alloca.h... yes checking for alloca... yes checking for double... yes checking size of double... 8 checking for long double... yes checking size of long double... 12 checking whether byte ordering is bigendian... no checking whether .eh_frame section should be read-only... no checking for __attribute__((visibility("hidden")))... no configure: creating ./config.status config.status: creating include/ffi.h config.status: creating fficonfig.py config.status: creating fficonfig.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffitarget.h to include/ffitarget.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/include/ffi_common.h to include/ffi_common.h config.status: executing include commands config.status: executing src commands >>> X86_64 ['src/prep_cif.c', 'src/x86/ffi64.c', 'src/x86/unix64.S', 'src/x86/sysv.S', 'src/x86/ffi.c'] building '_ctypes' extension /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c: In function `_CallProc': /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c:917: warning: implicit declaration of function `alloca' /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:177: warning: function declaration isn't a prototype /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:194: warning: function declaration isn't a prototype /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I added a couple prints to fficonfig.py.in to demonstrate the file order and platform name (and to make sure fficonfig.py was being rebuilt). Oddly enough, if I remove both ffi.o and sysv.o from the link line, it links successfully. Is that significant or am I just getting desparate? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-01 15:02 Message: Logged In: YES user_id=11105 I didn't know there are any systems that depend on the order of object files on the linker command line any more ;-). IIUC, the objects list is derived by distutils from the sources list, so the attached patch (for Modules/_ctypes/libffi/fficonfig.py.in) *could* do the trick. Please make sure that fficonfig.py is recreated (by doing make clean before building or whatever). Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-01 11:16 Message: Logged In: YES user_id=44345 Thomas> Skip, do you have *any* idea what might be Thomas> wrong, or could you even come up with a patch? Skip> I've no idea so far. I'll try to find some time Skip> to take a look at it later today. Thomas, Sorry for the delay. I think I have it figured out and it was fairly straightforward. Looking at the files in order on the _ctypes.so link line we see that the definition of ffi_closure_SYSV_inner is defined before it's referenced: for obj in build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ; do echo $obj; nm -p $obj | egrep ffi_closure_SYSV_inner; done build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o 0000000456 T ffi_closure_SYSV_inner build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o 0000000000 U ffi_closure_SYSV_inner Since we're linking from object files, it's a one-pass link algorithm. At the time ffo.o is examined, sysv.o hasn't been seen. Consequently, ffi_closure_SYSV_inner is not yet known and its definition isn't picked up from ffi.o. I couldn't quickly figure out where the link command is generated, but I'm sure you'll know where it resides. Either swap ffi.o and sysv.o on the link line, or add ffi.o a second time to resolve the new reference. Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-31 05:54 Message: Logged In: YES user_id=11105 Skip, do you have *any* idea what might be wrong, or could you even come up with a patch? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-07-28 17:03 Message: Logged In: YES user_id=44345 Yeah, you'd definitely need -fPIC on any brand of Solaris. That test might be changed to plat = get_platform() if plat in (... buncha platforms ...) or "solaris" in plat: os.environ["CFLAGS"] = "-fPIC" That doesn't seem to be what's happening in this case though. I rm'd the .o files in .../Modules/_ctypes and tried again. The compile commands *do* have -fPIC on them. I don't think it's required on the link line. S ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-28 11:19 Message: Logged In: YES user_id=11105 Skip, This looks *somewhat* like the problems reported in bugs 1529269 and 1528620 (although they have a sparc, and you seem to have x86 solaris). Hm, in the standalone ctypes setup script, I find this code snippet: if get_platform() in ["solaris-2.9-sun4u", "linux-x86_64"]: os.environ["CFLAGS"] = "-fPIC" Can it be that -fPIC must be used, but is not specified? It is also funny that the solaris buildbot does NOT seem to have a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 From noreply at sourceforge.net Thu Aug 3 22:12:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 13:12:19 -0700 Subject: [ python-Bugs-1522046 ] RPM build fails for Py2.5b2 Message-ID: Bugs item #1522046, was opened at 2006-07-13 13:55 Message generated for change (Comment added) made by breadman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522046&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Behnel (scoder) Assigned to: Nobody/Anonymous (nobody) Summary: RPM build fails for Py2.5b2 Initial Comment: Using Misc/RPM/python-2.5.spec, Python 2.5b2 fails to compile into an RPM on my machine (SuSE 10.1, AMD64, gcc 4.1). Unlike with b1, I get loads of errors saying: "ld: cannot find -lpython2.5" The funny thing is that it continues to build and only fails at the end when collecting the files for the RPM. I use configure --enable-shared --enable-unicode=ucs4 \ --enable-ipv6 --with-pymalloc --prefix=/usr \ --libdir=/usr/lib64 The shared library is correctly built before these errors come up. The error appear on the "sharedmods" target. I also tried setting LD_LIBRARY_PATH by hand, although the build script sets it before starting to build the modules - no help. What *does* help is adding "-L." to the LDFLAGS in Makefile.pre.in: sed -e '/DIR=.*lib$/ s|/lib$|/%{libdirname}| ; \ /LDFLAGS/ s|LDFLAGS=|LDFLAGS= -L. |' \ ./Makefile.pre.in.old >Makefile.pre.in The "DIR=" is for an x86_64 bug that installs Python to the wrong directory (/usr/lib instead of /usr/lib64). I tried building Py2.5 by hand (configure/make) and that also works nicely. I attached a patch that fixes the problems I encountered. ---------------------------------------------------------------------- Comment By: Eric Wald (breadman) Date: 2006-08-03 14:12 Message: Logged In: YES user_id=324500 There is a deeper issue here: Dynamic extensions fail to link until after libpython2.5.so.1.0 is installed. The '-L.' flag is the better approach to fixing this bug, but perhaps it should use the full path name, like the LD_LIBRARY_PATH environment variable used when running setup.py. Unfortunately, this bug is hidden from people compiling on top of an earlier 2.5 installation, where the link step will find and use the old library; for others, it is resolved in installation, where make will happily link the extensions if they failed to link earlier, right after installing the library. However, it means that the dynamic libraries are unavailable between the build and install steps. One major result is that the test suite refuses to run at that time. It also means that 'make install' can cause the linker to be called, which is generally discouraged. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522046&group_id=5470 From noreply at sourceforge.net Thu Aug 3 22:14:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 13:14:26 -0700 Subject: [ python-Bugs-1530448 ] ctypes build fails on Solaris 10 Message-ID: Bugs item #1530448, was opened at 2006-07-28 10:04 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 15:14 Message: Logged In: YES user_id=44345 When I manually link _ctypes.o with -mimpure-text the link succeeds, but applying it to the configure script had no discernable effect. Was I supposed to apply it to the top-level Python configure script or to one deeper in the tree? Skip ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 15:02 Message: Logged In: YES user_id=44345 Thomas, I did an svn up (rev 51078), deleted any local changes, created a new build directory, configured and built. I got the same error about ffi_closure_SYSV_inner. I then manually reran the link command without mention of ffi.o or sysv.o. It linked fine but when I ran make again it complained that _ctypes.so couldn't resolve ffi_prep_closure. This symbol is defined in ffi.o, so it appears either that ffi.c is needed in the source list or maybe ffi64.c needs to be modified to provide it. As far as I can tell it doesn't export any useful symbols: $ nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 f ffi64.c Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 14:36 Message: Logged In: YES user_id=11105 Correction: The option is '-mimpure-text', not '-impure-text'. I've attached a new patch 'setup.py.patch' which allows to build on the sourceforge solaris-x86 machine. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 14:28 Message: Logged In: YES user_id=11105 And, BTW, building the bz2 extension on the compile farm solaris-x86 machine also fails with relocation errors (but I have no idea if that is related to the _ctypes build failure or not). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 14:24 Message: Logged In: YES user_id=11105 What I've found out, after some painful time on the sourceforge compilefarm, is this: Python svn trunk also fails to build _ctypes.so on the solaris-x86 machine, but not on the sparc machines (both have solaris 9, I believe). ctypes from svn trunk *does* build also on the x86 machine, with the system installed python2.3, also with python 2.5b2. One difference that I found is that ctypes svn setup.py passes '-impure-text' to the linker, while python svn (when building the bundled ctypes) does not. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-02 08:20 Message: Logged In: YES user_id=11105 It seems that the files 'src/x86/ffi.c' and 'src/x86/sysv.S' are not needed for the X86_64 platform in fficonfig.py.in. They *should* compile to nothing, anyway, because their contents is protected by 'ifndef __x86_64__'. Does removing them from fficonfig.py.in change the situation, so that only this remains: 'X86_64': ['src/x86/ffi64.c', 'src/x86/unix64.S'], I can build _ctypes on an unbuntu amd64 system with this change. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-02 08:08 Message: Logged In: YES user_id=44345 I don't understand. I swapped the order of ffi.c and sysv.S in the platforms dict. I confirmed that the order of the .o files on the link line changed so that ffi.o followed sysv.o. I still get the same error. I've also confirmed that ffi.o exports the symbol and that sysv.o references it: % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 U _GLOBAL_OFFSET_TABLE_ 0000000000 f ffi.c 0000000332 T ffi_call 0000000000 U ffi_call_SYSV 0000000000 U ffi_closure_SYSV 0000000456 T ffi_closure_SYSV_inner 0000000000 T ffi_prep_args 0000000252 T ffi_prep_cif_machdep 0000000612 T ffi_prep_closure 0000000000 U memcpy % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000109 n epilogue 0000000000 T ffi_call_SYSV 0000000116 T ffi_closure_SYSV 0000000000 U ffi_closure_SYSV_inner 0000000000 U ffi_prep_args 0000000109 n noretval 0000000071 n retdouble 0000000059 n retfloat 0000000046 n retint 0000000095 n retint64 0000000083 n retlongdouble 0000000109 n retstruct All the object files were compiled with -fPIC. Here's the relevant chunk of make's output: creating build/temp.solaris-2.10-i86pc-2.5/libffi checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for gcc... /opt/app/g++lib6/gcc-3.4/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /opt/app/g++lib6/gcc-3.4/bin/gcc accepts -g... yes checking for /opt/app/g++lib6/gcc-3.4/bin/gcc option to accept ANSI C... none needed checking how to run the C preprocessor... /opt/app/g++lib6/gcc-3.4/bin/gcc -E checking for egrep... egrep checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking sys/mman.h usability... yes checking sys/mman.h presence... yes checking for sys/mman.h... yes checking for mmap... yes checking for sys/mman.h... (cached) yes checking for mmap... (cached) yes checking whether read-only mmap of a plain file works... yes checking whether mmap from /dev/zero works... yes checking for MAP_ANON(YMOUS)... yes checking whether mmap with MAP_ANON(YMOUS) works... yes checking for ANSI C header files... (cached) yes checking for memcpy... yes checking for working alloca.h... yes checking for alloca... yes checking for double... yes checking size of double... 8 checking for long double... yes checking size of long double... 12 checking whether byte ordering is bigendian... no checking whether .eh_frame section should be read-only... no checking for __attribute__((visibility("hidden")))... no configure: creating ./config.status config.status: creating include/ffi.h config.status: creating fficonfig.py config.status: creating fficonfig.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffitarget.h to include/ffitarget.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/include/ffi_common.h to include/ffi_common.h config.status: executing include commands config.status: executing src commands >>> X86_64 ['src/prep_cif.c', 'src/x86/ffi64.c', 'src/x86/unix64.S', 'src/x86/sysv.S', 'src/x86/ffi.c'] building '_ctypes' extension /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c: In function `_CallProc': /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c:917: warning: implicit declaration of function `alloca' /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:177: warning: function declaration isn't a prototype /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:194: warning: function declaration isn't a prototype /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I added a couple prints to fficonfig.py.in to demonstrate the file order and platform name (and to make sure fficonfig.py was being rebuilt). Oddly enough, if I remove both ffi.o and sysv.o from the link line, it links successfully. Is that significant or am I just getting desparate? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-01 15:02 Message: Logged In: YES user_id=11105 I didn't know there are any systems that depend on the order of object files on the linker command line any more ;-). IIUC, the objects list is derived by distutils from the sources list, so the attached patch (for Modules/_ctypes/libffi/fficonfig.py.in) *could* do the trick. Please make sure that fficonfig.py is recreated (by doing make clean before building or whatever). Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-01 11:16 Message: Logged In: YES user_id=44345 Thomas> Skip, do you have *any* idea what might be Thomas> wrong, or could you even come up with a patch? Skip> I've no idea so far. I'll try to find some time Skip> to take a look at it later today. Thomas, Sorry for the delay. I think I have it figured out and it was fairly straightforward. Looking at the files in order on the _ctypes.so link line we see that the definition of ffi_closure_SYSV_inner is defined before it's referenced: for obj in build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ; do echo $obj; nm -p $obj | egrep ffi_closure_SYSV_inner; done build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o 0000000456 T ffi_closure_SYSV_inner build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o 0000000000 U ffi_closure_SYSV_inner Since we're linking from object files, it's a one-pass link algorithm. At the time ffo.o is examined, sysv.o hasn't been seen. Consequently, ffi_closure_SYSV_inner is not yet known and its definition isn't picked up from ffi.o. I couldn't quickly figure out where the link command is generated, but I'm sure you'll know where it resides. Either swap ffi.o and sysv.o on the link line, or add ffi.o a second time to resolve the new reference. Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-31 05:54 Message: Logged In: YES user_id=11105 Skip, do you have *any* idea what might be wrong, or could you even come up with a patch? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-07-28 17:03 Message: Logged In: YES user_id=44345 Yeah, you'd definitely need -fPIC on any brand of Solaris. That test might be changed to plat = get_platform() if plat in (... buncha platforms ...) or "solaris" in plat: os.environ["CFLAGS"] = "-fPIC" That doesn't seem to be what's happening in this case though. I rm'd the .o files in .../Modules/_ctypes and tried again. The compile commands *do* have -fPIC on them. I don't think it's required on the link line. S ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-28 11:19 Message: Logged In: YES user_id=11105 Skip, This looks *somewhat* like the problems reported in bugs 1529269 and 1528620 (although they have a sparc, and you seem to have x86 solaris). Hm, in the standalone ctypes setup script, I find this code snippet: if get_platform() in ["solaris-2.9-sun4u", "linux-x86_64"]: os.environ["CFLAGS"] = "-fPIC" Can it be that -fPIC must be used, but is not specified? It is also funny that the solaris buildbot does NOT seem to have a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 From noreply at sourceforge.net Thu Aug 3 22:21:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 13:21:50 -0700 Subject: [ python-Bugs-1032875 ] ftplib has incomplete transfer when sending files in Windows Message-ID: Bugs item #1032875, was opened at 2004-09-22 15:21 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032875&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: Ed Sanville (infinity314) Assigned to: Nobody/Anonymous (nobody) Summary: ftplib has incomplete transfer when sending files in Windows Initial Comment: I wrote the following short script: from ftplib import FTP ftp=FTP('ftp.edsanville.us', username, password) print ftp.getwelcome() print ftp.storbinary('stor test.xls', file('test.xls', 'r')) ftp.quit() It transfers the entire file under Red Hat Linux 9, but under Windows XP, it only transfers a couple kilobytes at most. Using a hex editor, I found that the first 5 or 6 bytes of the file are OK on the remote side after transfer, but the rest of the file is totally wrong. I'm at a loss, it doesn't make any sense. Please, somebody tell me I'm not insane. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 16:21 Message: Logged In: YES user_id=11375 No further word on this bug, and it seems likely to have been the 'rb' issue. Closing this bug. ---------------------------------------------------------------------- Comment By: engelbert gruber (grubert) Date: 2004-10-05 22:50 Message: Logged In: YES user_id=147070 For binary files on windows one has to use file('test.xls','rb'). if this works please close the bug. ---------------------------------------------------------------------- Comment By: engelbert gruber (grubert) Date: 2004-10-05 10:19 Message: Logged In: YES user_id=147070 looks like a file problem: f=open('test.xls');d=f.read() reads all the file. on winxp/py234 not making a binary file: for i in range(0,50):for d in range(0,255): f.write(d) reading it: d=f.read() 1.round len(d) = 26, f.tell() 12288 2.round len(d) = 26, f.tell() 12800 chr(26) is the end of a dos textfile. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1032875&group_id=5470 From noreply at sourceforge.net Thu Aug 3 22:34:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 13:34:20 -0700 Subject: [ python-Bugs-1234123 ] datetime.strftime %s Message-ID: Bugs item #1234123, was opened at 2005-07-07 07:39 Message generated for change (Comment added) made by akuchling 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: Closed >Resolution: Postponed 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 ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 16:34 Message: Logged In: YES user_id=11375 Given that tzinfo is coming from the pytz package, which is external to Python, it seems unlikely that this is a Python bug. If the pytz developers ultimately track down the problem to a Python bug, they can surely provide a test case for Python that doesn't depend on external software. Closing this bug; it can be reopened if it turns out to be a Python problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1234123&group_id=5470 From noreply at sourceforge.net Thu Aug 3 22:37:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 13:37:38 -0700 Subject: [ python-Bugs-1530448 ] ctypes build fails on Solaris 10 Message-ID: Bugs item #1530448, was opened at 2006-07-28 10:04 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 15:37 Message: Logged In: YES user_id=44345 make that "_ctypes.so"... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 15:14 Message: Logged In: YES user_id=44345 When I manually link _ctypes.o with -mimpure-text the link succeeds, but applying it to the configure script had no discernable effect. Was I supposed to apply it to the top-level Python configure script or to one deeper in the tree? Skip ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 15:02 Message: Logged In: YES user_id=44345 Thomas, I did an svn up (rev 51078), deleted any local changes, created a new build directory, configured and built. I got the same error about ffi_closure_SYSV_inner. I then manually reran the link command without mention of ffi.o or sysv.o. It linked fine but when I ran make again it complained that _ctypes.so couldn't resolve ffi_prep_closure. This symbol is defined in ffi.o, so it appears either that ffi.c is needed in the source list or maybe ffi64.c needs to be modified to provide it. As far as I can tell it doesn't export any useful symbols: $ nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 f ffi64.c Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 14:36 Message: Logged In: YES user_id=11105 Correction: The option is '-mimpure-text', not '-impure-text'. I've attached a new patch 'setup.py.patch' which allows to build on the sourceforge solaris-x86 machine. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 14:28 Message: Logged In: YES user_id=11105 And, BTW, building the bz2 extension on the compile farm solaris-x86 machine also fails with relocation errors (but I have no idea if that is related to the _ctypes build failure or not). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 14:24 Message: Logged In: YES user_id=11105 What I've found out, after some painful time on the sourceforge compilefarm, is this: Python svn trunk also fails to build _ctypes.so on the solaris-x86 machine, but not on the sparc machines (both have solaris 9, I believe). ctypes from svn trunk *does* build also on the x86 machine, with the system installed python2.3, also with python 2.5b2. One difference that I found is that ctypes svn setup.py passes '-impure-text' to the linker, while python svn (when building the bundled ctypes) does not. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-02 08:20 Message: Logged In: YES user_id=11105 It seems that the files 'src/x86/ffi.c' and 'src/x86/sysv.S' are not needed for the X86_64 platform in fficonfig.py.in. They *should* compile to nothing, anyway, because their contents is protected by 'ifndef __x86_64__'. Does removing them from fficonfig.py.in change the situation, so that only this remains: 'X86_64': ['src/x86/ffi64.c', 'src/x86/unix64.S'], I can build _ctypes on an unbuntu amd64 system with this change. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-02 08:08 Message: Logged In: YES user_id=44345 I don't understand. I swapped the order of ffi.c and sysv.S in the platforms dict. I confirmed that the order of the .o files on the link line changed so that ffi.o followed sysv.o. I still get the same error. I've also confirmed that ffi.o exports the symbol and that sysv.o references it: % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 U _GLOBAL_OFFSET_TABLE_ 0000000000 f ffi.c 0000000332 T ffi_call 0000000000 U ffi_call_SYSV 0000000000 U ffi_closure_SYSV 0000000456 T ffi_closure_SYSV_inner 0000000000 T ffi_prep_args 0000000252 T ffi_prep_cif_machdep 0000000612 T ffi_prep_closure 0000000000 U memcpy % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000109 n epilogue 0000000000 T ffi_call_SYSV 0000000116 T ffi_closure_SYSV 0000000000 U ffi_closure_SYSV_inner 0000000000 U ffi_prep_args 0000000109 n noretval 0000000071 n retdouble 0000000059 n retfloat 0000000046 n retint 0000000095 n retint64 0000000083 n retlongdouble 0000000109 n retstruct All the object files were compiled with -fPIC. Here's the relevant chunk of make's output: creating build/temp.solaris-2.10-i86pc-2.5/libffi checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for gcc... /opt/app/g++lib6/gcc-3.4/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /opt/app/g++lib6/gcc-3.4/bin/gcc accepts -g... yes checking for /opt/app/g++lib6/gcc-3.4/bin/gcc option to accept ANSI C... none needed checking how to run the C preprocessor... /opt/app/g++lib6/gcc-3.4/bin/gcc -E checking for egrep... egrep checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking sys/mman.h usability... yes checking sys/mman.h presence... yes checking for sys/mman.h... yes checking for mmap... yes checking for sys/mman.h... (cached) yes checking for mmap... (cached) yes checking whether read-only mmap of a plain file works... yes checking whether mmap from /dev/zero works... yes checking for MAP_ANON(YMOUS)... yes checking whether mmap with MAP_ANON(YMOUS) works... yes checking for ANSI C header files... (cached) yes checking for memcpy... yes checking for working alloca.h... yes checking for alloca... yes checking for double... yes checking size of double... 8 checking for long double... yes checking size of long double... 12 checking whether byte ordering is bigendian... no checking whether .eh_frame section should be read-only... no checking for __attribute__((visibility("hidden")))... no configure: creating ./config.status config.status: creating include/ffi.h config.status: creating fficonfig.py config.status: creating fficonfig.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffitarget.h to include/ffitarget.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/include/ffi_common.h to include/ffi_common.h config.status: executing include commands config.status: executing src commands >>> X86_64 ['src/prep_cif.c', 'src/x86/ffi64.c', 'src/x86/unix64.S', 'src/x86/sysv.S', 'src/x86/ffi.c'] building '_ctypes' extension /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c: In function `_CallProc': /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c:917: warning: implicit declaration of function `alloca' /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:177: warning: function declaration isn't a prototype /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:194: warning: function declaration isn't a prototype /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I added a couple prints to fficonfig.py.in to demonstrate the file order and platform name (and to make sure fficonfig.py was being rebuilt). Oddly enough, if I remove both ffi.o and sysv.o from the link line, it links successfully. Is that significant or am I just getting desparate? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-01 15:02 Message: Logged In: YES user_id=11105 I didn't know there are any systems that depend on the order of object files on the linker command line any more ;-). IIUC, the objects list is derived by distutils from the sources list, so the attached patch (for Modules/_ctypes/libffi/fficonfig.py.in) *could* do the trick. Please make sure that fficonfig.py is recreated (by doing make clean before building or whatever). Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-01 11:16 Message: Logged In: YES user_id=44345 Thomas> Skip, do you have *any* idea what might be Thomas> wrong, or could you even come up with a patch? Skip> I've no idea so far. I'll try to find some time Skip> to take a look at it later today. Thomas, Sorry for the delay. I think I have it figured out and it was fairly straightforward. Looking at the files in order on the _ctypes.so link line we see that the definition of ffi_closure_SYSV_inner is defined before it's referenced: for obj in build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ; do echo $obj; nm -p $obj | egrep ffi_closure_SYSV_inner; done build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o 0000000456 T ffi_closure_SYSV_inner build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o 0000000000 U ffi_closure_SYSV_inner Since we're linking from object files, it's a one-pass link algorithm. At the time ffo.o is examined, sysv.o hasn't been seen. Consequently, ffi_closure_SYSV_inner is not yet known and its definition isn't picked up from ffi.o. I couldn't quickly figure out where the link command is generated, but I'm sure you'll know where it resides. Either swap ffi.o and sysv.o on the link line, or add ffi.o a second time to resolve the new reference. Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-31 05:54 Message: Logged In: YES user_id=11105 Skip, do you have *any* idea what might be wrong, or could you even come up with a patch? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-07-28 17:03 Message: Logged In: YES user_id=44345 Yeah, you'd definitely need -fPIC on any brand of Solaris. That test might be changed to plat = get_platform() if plat in (... buncha platforms ...) or "solaris" in plat: os.environ["CFLAGS"] = "-fPIC" That doesn't seem to be what's happening in this case though. I rm'd the .o files in .../Modules/_ctypes and tried again. The compile commands *do* have -fPIC on them. I don't think it's required on the link line. S ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-28 11:19 Message: Logged In: YES user_id=11105 Skip, This looks *somewhat* like the problems reported in bugs 1529269 and 1528620 (although they have a sparc, and you seem to have x86 solaris). Hm, in the standalone ctypes setup script, I find this code snippet: if get_platform() in ["solaris-2.9-sun4u", "linux-x86_64"]: os.environ["CFLAGS"] = "-fPIC" Can it be that -fPIC must be used, but is not specified? It is also funny that the solaris buildbot does NOT seem to have a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 From noreply at sourceforge.net Thu Aug 3 22:50:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 13:50:38 -0700 Subject: [ python-Bugs-788035 ] missing universal newline support in os.popen & friends Message-ID: Bugs item #788035, was opened at 2003-08-13 09:17 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788035&group_id=5470 Please note that this 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: Torsten Marek (shlomme) Assigned to: Nobody/Anonymous (nobody) Summary: missing universal newline support in os.popen & friends Initial Comment: In contrast to the documentation, os.popen and relatives do not support the "U" format character in their constructors. os.popen("some_nifty_command some_arg", "rU") throws OSError: [Errno 22] Invalid argument , while os.popen{2,3,4} just ignores "U". I noticed that behaviour while p-opening oggenc (the ogg vorbis encoder), which uses curses for output. The lines end with \r and not with \n (due to some ncurses internals, I suspect), so that the file objects readline() function cannot split the output. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 16:50 Message: Logged In: YES user_id=11375 popen5 was added to Python 2.4 as the subprocess module. It's probably unlikely that someone will go back and fix the low-level os.popen2() function. I suggest that this bug be closed, and we encourage people to use the subprocess module. ---------------------------------------------------------------------- Comment By: Philip Lindsay (philiplindsay) Date: 2004-01-13 05:46 Message: Logged In: YES user_id=254205 See http://advogato.org/person/follower/diary.html?start=43 for details of a possible interim work around. (WFM, YMMV) ---------------------------------------------------------------------- Comment By: Philip Lindsay (philiplindsay) Date: 2004-01-13 05:45 Message: Logged In: YES user_id=254205 See for details of a possible interim work around. (WFM, YMMV) ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2003-11-03 15:01 Message: Logged In: YES user_id=344921 I've added universal newline support to popen5. http://www.lysator.liu.se/~astrand/popen5/. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-26 18:04 Message: Logged In: YES user_id=45365 Theoretically this is easy to fix: if mode=="U" or "rU" just pass "r" to popen(), "rb" to fdopen() and _O_BINARY to the lowlevel calls, and the original string to PyFile_FromFile. But this whole popen{,2,3,4} section of posixmodule.c is so fiendishly complicated with all the platform special cases that I'm loath to touch it... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788035&group_id=5470 From noreply at sourceforge.net Thu Aug 3 22:55:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 13:55:57 -0700 Subject: [ python-Bugs-1081879 ] Pydoc can't find browser (bug+solution!) Message-ID: Bugs item #1081879, was opened at 2004-12-09 00:14 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081879&group_id=5470 Please note that this 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: Stewart Midwinter (midtoad) Assigned to: Nobody/Anonymous (nobody) Summary: Pydoc can't find browser (bug+solution!) Initial Comment: I've got Python 2.3 installed on Mandrake Linux 10.1 with KDE 3.2 running. When I run "pydoc -g" and search on any term, if I try to display the relevant documentation, pydoc throws an exception: Traceback (most recent call last): File "/usr/lib/python2.3/lib-tk/Tkinter.py", line 1345, in __call__ return self.func(*args) File "/usr/lib/python2.3/pydoc.py", line 1970, in open webbrowser.open(url) File "/usr/lib/python2.3/webbrowser.py", line 43, in open get().open(url, new, autoraise) File "/usr/lib/python2.3/webbrowser.py", line 38, in get raise Error("could not locate runnable browser") Error: could not locate runnable browser I did some research and found that the problem is that KDE sets the BROWSER environment variable to an unexpected value: BROWSER='kfmclient openProfile webbrowsing' The solution would be to test for this strange setting. I patched webbrowser.py on my system in an inelegant fashion by simply inserting the following code at the top of the file, just after the 'import' statements: #patch for KDE mangling of BROWSER environment variable #per: http://mail.python.org/pipermail/tutor/2004-September/032060.html if os.environ.has_key("BROWSER") and \ os.environ["BROWSER"]=='kfmclient openProfile webbrowsing': os.environ["BROWSER"] = 'konqueror' # set it to konqueror ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 16:55 Message: Logged In: YES user_id=11375 Or perhaps webbrowser.py should execute the command using os.system() or some similar mechanism that would split on the whitespace and treat the additional arguments correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1081879&group_id=5470 From noreply at sourceforge.net Thu Aug 3 22:58:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 13:58:14 -0700 Subject: [ python-Bugs-1025395 ] email.Utils.parseaddr fails to parse valid addresses Message-ID: Bugs item #1025395, was opened at 2004-09-09 16:43 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025395&group_id=5470 Please note that this 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: Charles (melicertes) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Utils.parseaddr fails to parse valid addresses Initial Comment: email.Utils.parseaddr() does not successfully parse a field value into a (comment, address) pair if the address contains a source route with more than one hop. i.e., it is successfully parses this: "God" <@hop1.org:jeff at spec.org> to get the address , but it fails to do the same if supplied with a 2-hop source route: "God" <@hop1.org, at hop2.net:jeff at spec.org> In this case, it gets the comment ("God") right, but fails to extract the address. Multi-hop source routes, while deprecated, are still valid in rfc2822. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1025395&group_id=5470 From noreply at sourceforge.net Thu Aug 3 23:18:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 14:18:35 -0700 Subject: [ python-Bugs-1068477 ] linecache.py::updatecache strips directory info from files Message-ID: Bugs item #1068477, was opened at 2004-11-18 01:32 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1068477&group_id=5470 Please note that this 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: Tim Leslie (tleslie) Assigned to: Nobody/Anonymous (nobody) Summary: linecache.py::updatecache strips directory info from files Initial Comment: If a filename couldn't be stat()ed, the code tries to find it in sys.path. To do this it only takes the filename and drops any preceding directories. If the file happens to reside in a package, the name of the package is lost, which can lead to badness. Eg, if you have my_package/__init__.py, then just the file __init__.py will be searched for, which may well be found in the cache from a different package. This leads to the wrong file being returned. This bit me as a result of using pydoc on a set of my packages. I'll try to put together a minimal example which demonstates the behaviour. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 17:18 Message: Logged In: YES user_id=11375 In 2.5trunk, linecache seems to be broken in a different way; the files are never added to the cache at all, and getlines() returns an empty list. One problem is that, when updatecache searches through sys.path, it does os.path.join(path, basename), not filename, so it looks for ./__init__.py, not ./pkg1/__init__.py. Changing it to filename makes the test script work in 2.5. It's not clear if linecache really intends to support multiple-component filenames, though. I think it should, though. ---------------------------------------------------------------------- Comment By: Tim Leslie (tleslie) Date: 2004-11-18 19:20 Message: Logged In: YES user_id=1081664 I can also confirm that this bug exists in python2.4b2. ---------------------------------------------------------------------- Comment By: Tim Leslie (tleslie) Date: 2004-11-18 18:43 Message: Logged In: YES user_id=1081664 Running the attached code ( from ~/src, not ~/src/pybug) we see that the contents of the cache are incorrect). timl at newton:~/src$ tar -zxvf pybug.tar.gz pybug/ pybug/pkg1/ pybug/pkg1/__init__.py pybug/pkg2/ pybug/pkg2/__init__.py pybug/bug.py timl at newton:~/src$ python pybug/bug.py {'pkg2/__init__.py': (217L, 1051027884, ['#\n', '# The Python Imaging Library.\n', '# $Id: //modules/pil/PIL/__init__.py#2 $\n', '#\n', '# package placeholder\n', '#\n', '# Copyright (c) 1999 by Secret Labs AB.\n', '#\n', '# See the README file for information on usage and redistribution.\n', '#\n', '\n', '# ;-)\n'], '/usr/lib/python2.3/site-packages/PIL/__init__.py'), 'pkg1/__init__.py': (217L, 1051027884, ['#\n', '# The Python Imaging Library.\n', '# $Id: //modules/pil/PIL/__init__.py#2 $\n', '#\n', '# package placeholder\n', '#\n', '# Copyright (c) 1999 by Secret Labs AB.\n', '#\n', '# See the README file for information on usage and redistribution.\n', '#\n', '\n', '# ;-)\n'], '/usr/lib/python2.3/site-packages/PIL/__init__.py')} timl at newton:~/src$ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1068477&group_id=5470 From noreply at sourceforge.net Thu Aug 3 23:24:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 14:24:15 -0700 Subject: [ python-Bugs-1433886 ] pointer aliasing causes core dump, with workaround Message-ID: Bugs item #1433886, was opened at 2006-02-17 17:56 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&group_id=5470 Please note that this 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: Quentin Barnes (qbarnes) >Assigned to: Tim Peters (tim_one) Summary: pointer aliasing causes core dump, with workaround Initial Comment: When building 2.3.3 on Solaris using Studio 11 and "-xalias_level=std" to enable ISO C99 pointer aliasing rules, the interpreter would core dump when running test_descr2.py. From examining the source, I believe this problem exists in 2.4.2 as well, but did not verify it. I was able to simplify the code to invoke the problem down to: ==== class C1(object): def __new__(cls): return super(C1, cls).__new__(cls) a = C1() ==== I tracked the problem to super_init() in Objects/typeobject.c. The local variable "obj" is of type "PyObject *" and "type" is of type "PyTypeObject *". In this function, both variables can be pointing to the same object in memory. Since the pointers are not of compatible types, the compiler ends up optimizing out a memory load between Py_INCREF(obj) and Py_INCREF(type) caching a previously read value. This causes the object reference counter to only be incremented once instead of twice. When the object is deallocated, the interpreter blows up. A workaround is to cast one of the pointers to the others type so that the compiler can see the pointer aliasing potential. This is what I did in the patch. What I suspect needs to be done as a more global fix is to discontinue use of the PyObject_VAR_HEAD macro hack. Casting between structures containing this macro creates ISO C99 pointer aliasing violations. The contents of the macro needs to be in its own structure which is referenced so a compliant compiler can know of possible aliasing. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 17:24 Message: Logged In: YES user_id=11375 I have the vague impression that Python's code doesn't conform to strict aliasing, and it therefore must always be compiled with GCC's -fno-strict-aliasing option or the equivalent. Your fix might avoid that one problem, but there might be other subtle bugs. Assigning to Tim Peters, who will know if the -fno-strict-aliasing statement is correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&group_id=5470 From noreply at sourceforge.net Fri Aug 4 04:24:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 19:24:54 -0700 Subject: [ python-Bugs-1433886 ] pointer aliasing causes core dump, with workaround Message-ID: Bugs item #1433886, was opened at 2006-02-17 16:56 Message generated for change (Comment added) made by qbarnes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&group_id=5470 Please note that this 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: Quentin Barnes (qbarnes) Assigned to: Tim Peters (tim_one) Summary: pointer aliasing causes core dump, with workaround Initial Comment: When building 2.3.3 on Solaris using Studio 11 and "-xalias_level=std" to enable ISO C99 pointer aliasing rules, the interpreter would core dump when running test_descr2.py. From examining the source, I believe this problem exists in 2.4.2 as well, but did not verify it. I was able to simplify the code to invoke the problem down to: ==== class C1(object): def __new__(cls): return super(C1, cls).__new__(cls) a = C1() ==== I tracked the problem to super_init() in Objects/typeobject.c. The local variable "obj" is of type "PyObject *" and "type" is of type "PyTypeObject *". In this function, both variables can be pointing to the same object in memory. Since the pointers are not of compatible types, the compiler ends up optimizing out a memory load between Py_INCREF(obj) and Py_INCREF(type) caching a previously read value. This causes the object reference counter to only be incremented once instead of twice. When the object is deallocated, the interpreter blows up. A workaround is to cast one of the pointers to the others type so that the compiler can see the pointer aliasing potential. This is what I did in the patch. What I suspect needs to be done as a more global fix is to discontinue use of the PyObject_VAR_HEAD macro hack. Casting between structures containing this macro creates ISO C99 pointer aliasing violations. The contents of the macro needs to be in its own structure which is referenced so a compliant compiler can know of possible aliasing. ---------------------------------------------------------------------- >Comment By: Quentin Barnes (qbarnes) Date: 2006-08-03 21:24 Message: Logged In: YES user_id=288734 There is no reason why the source code for Python cannot conform to ISO C99 pointer aliasing rules. If pointers are being improperly aliased violating the C standard, it's just bad programming practice. The only reason to use a switch like GCC's -fno-strict-aliasing or Solaris' -xalias_level=any is for old legacy code, not well-programmed, actively maintained code. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 16:24 Message: Logged In: YES user_id=11375 I have the vague impression that Python's code doesn't conform to strict aliasing, and it therefore must always be compiled with GCC's -fno-strict-aliasing option or the equivalent. Your fix might avoid that one problem, but there might be other subtle bugs. Assigning to Tim Peters, who will know if the -fno-strict-aliasing statement is correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&group_id=5470 From noreply at sourceforge.net Fri Aug 4 04:47:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 19:47:39 -0700 Subject: [ python-Bugs-1433886 ] pointer aliasing causes core dump, with workaround Message-ID: Bugs item #1433886, was opened at 2006-02-17 17:56 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&group_id=5470 Please note that this 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: Quentin Barnes (qbarnes) >Assigned to: Nobody/Anonymous (nobody) Summary: pointer aliasing causes core dump, with workaround Initial Comment: When building 2.3.3 on Solaris using Studio 11 and "-xalias_level=std" to enable ISO C99 pointer aliasing rules, the interpreter would core dump when running test_descr2.py. From examining the source, I believe this problem exists in 2.4.2 as well, but did not verify it. I was able to simplify the code to invoke the problem down to: ==== class C1(object): def __new__(cls): return super(C1, cls).__new__(cls) a = C1() ==== I tracked the problem to super_init() in Objects/typeobject.c. The local variable "obj" is of type "PyObject *" and "type" is of type "PyTypeObject *". In this function, both variables can be pointing to the same object in memory. Since the pointers are not of compatible types, the compiler ends up optimizing out a memory load between Py_INCREF(obj) and Py_INCREF(type) caching a previously read value. This causes the object reference counter to only be incremented once instead of twice. When the object is deallocated, the interpreter blows up. A workaround is to cast one of the pointers to the others type so that the compiler can see the pointer aliasing potential. This is what I did in the patch. What I suspect needs to be done as a more global fix is to discontinue use of the PyObject_VAR_HEAD macro hack. Casting between structures containing this macro creates ISO C99 pointer aliasing violations. The contents of the macro needs to be in its own structure which is referenced so a compliant compiler can know of possible aliasing. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-08-03 22:47 Message: Logged In: YES user_id=31435 Yes, Python must be compiled with -fno-strict-aliasing (or moral equivalent). No, that's not going to change before Python 3000 (if even then). All Python object structs conceptually extend the PyObject struct, including (but not limited to) object structs conceptually extending the PyVarObject struct (which in turn conceptually extends the PyObject struct). This is uniquitous in the core source code, and in all 3rd-party extension modules defining new Python objects in C. Note that Python doesn't much care about C99. It was written against K&R C, and went nearly a decade before requiring C89 (it took that long for C89-conforming compilers to show up on all interesting Python platforms). Best guess is that it will never require C99 (because best guess is that C99-conforming compilers will never show up on all interesting Python platforms). That said, I don't see anything to object to in adding fiddly casting patches to make sure compilers don't try to exploit the trivial optimization opportunities that assuming no aliasing in the Python source may allow. ---------------------------------------------------------------------- Comment By: Quentin Barnes (qbarnes) Date: 2006-08-03 22:24 Message: Logged In: YES user_id=288734 There is no reason why the source code for Python cannot conform to ISO C99 pointer aliasing rules. If pointers are being improperly aliased violating the C standard, it's just bad programming practice. The only reason to use a switch like GCC's -fno-strict-aliasing or Solaris' -xalias_level=any is for old legacy code, not well-programmed, actively maintained code. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 17:24 Message: Logged In: YES user_id=11375 I have the vague impression that Python's code doesn't conform to strict aliasing, and it therefore must always be compiled with GCC's -fno-strict-aliasing option or the equivalent. Your fix might avoid that one problem, but there might be other subtle bugs. Assigning to Tim Peters, who will know if the -fno-strict-aliasing statement is correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&group_id=5470 From noreply at sourceforge.net Fri Aug 4 05:45:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 20:45:54 -0700 Subject: [ python-Bugs-1531003 ] __weaklist__ in typeobject.c Message-ID: Bugs item #1531003, was opened at 2006-07-29 12:57 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531003&group_id=5470 Please note that this 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: Fred L. Drake, Jr. (fdrake) Assigned to: Nobody/Anonymous (nobody) Summary: __weaklist__ in typeobject.c Initial Comment: typeobject.c:subtype_getweakref mentions __weaklist__ in an exception message that looks like it should refer to __weakref__. This exists in both 2.4 and the trunk. Fixing this should be just a matter of changing the message text; I don't see any other references to __weaklist__. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-03 20:45 Message: Logged In: YES user_id=33168 See patch 1534048 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531003&group_id=5470 From noreply at sourceforge.net Fri Aug 4 06:50:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 21:50:59 -0700 Subject: [ python-Bugs-1531405 ] format_exception raises if str(exception) raises Message-ID: Bugs item #1531405, was opened at 2006-07-30 14:06 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Jp Calderone (kuran) Assigned to: Neal Norwitz (nnorwitz) Summary: format_exception raises if str(exception) raises Initial Comment: Previously format_exception_only used _some_str() to find the string representation of an exception. In current trunk at HEAD that code has been factored into _format_final_exc_line and changed in two ways: it now calls str(exception) twice instead of once and in one of those cases, it calls str() directly rather than through _some_str, which does exception handling. The end result of this is that application-level code which uses the traceback module to format exceptions which previously could not raise exceptions now can raise exceptions. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-03 21:50 Message: Logged In: YES user_id=33168 Committed revision 51079. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-02 23:13 Message: Logged In: YES user_id=849994 I have a fix and will apply as soon as trunk is unfrozen. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-08-02 15:55 Message: Logged In: YES user_id=366566 I don't think those are related. To clarify, this is the case I am talking about: Python 2.5b2 (trunk:50989, Jul 30 2006, 15:42:25) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X: ... def __str__(self): 1/0 ... >>> import traceback >>> traceback.format_exception_only(X, X()) Traceback (most recent call last): File "", line 1, in File "/home/exarkun/Projects/python/trunk/Lib/traceback.py", line 179, in format_exception_only return [_format_final_exc_line(stype, value)] File "/home/exarkun/Projects/python/trunk/Lib/traceback.py", line 205, in _format_final_exc_line if value is None or not str(value): File "", line 2, in __str__ ZeroDivisionError: integer division or modulo by zero >>> Compare this to the Python 2.4 output: Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X: ... def __str__(self): 1/0 ... >>> import traceback >>> traceback.format_exception_only(X, X()) ['X: \n'] >>> ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-02 15:13 Message: Logged In: YES user_id=764593 Jp -- is this the same issue as 1515163 (patch 1515343)? If so, it should be cleared up in the traceback.py from head. Could you doublecheck? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531405&group_id=5470 From noreply at sourceforge.net Fri Aug 4 06:59:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 21:59:47 -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 nnorwitz 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: Closed >Resolution: Fixed Priority: 9 Submitted By: Brett Cannon (bcannon) Assigned to: Neal Norwitz (nnorwitz) 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: Neal Norwitz (nnorwitz) Date: 2006-08-03 21:59 Message: Logged In: YES user_id=33168 I believe everything in this report is fixed. If there are problems that are found, please open a new report so they will be easier to track. Committed revision 51080. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-02 22:59 Message: Logged In: YES user_id=33168 Fix pending. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2006-04-03 08:31 Message: Logged In: YES user_id=31392 Just wanted to note that I have fixes for the failing tests on my laptop. Need to sync with the current trunk before I can check in. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-10-25 15:03 Message: Logged In: YES user_id=357491 Yep, all tests pass, so that just leaves the test_trace tests that are currently commented out. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2005-10-23 21:51 Message: Logged In: YES user_id=35752 I believe the only remaining broken tests are the ones commented out in test_trace. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2005-10-07 11:46 Message: Logged In: YES user_id=31392 test_dis update: Fixed one of two failing tests. test_dis() was easy. test_bug_708901() is harder. The current AST only stores line numbers for statements. The test case is checking that the lnotab can assign a single statement multiple line numbers; in this case, the statement spans multiple lines and the disassembled code should reflect that. The fix is probably to add line numbers to expressions, which requires changing the AST definition and updating ast.c to assign line numbers. ---------------------------------------------------------------------- Comment By: Jeremy Hylton (jhylton) Date: 2005-10-07 11:01 Message: Logged In: YES user_id=31392 Here's a quick status report on Linux + GCC 3.2.2 from today: 12 tests failed: test_dis test_doctest test_future test_genexps test_inspect test_new test_peepholer test_pwd test_scope test_subprocess test_symtable test_trace 7 skips unexpected on linux2: test_hotshot test_bsddb test_email test_parser test_transformer test_email_codecs test_compiler I'm going to trace into the details of why each of these tests is failing. ---------------------------------------------------------------------- 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 Fri Aug 4 07:10:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 22:10:19 -0700 Subject: [ python-Bugs-1333982 ] Bugs of the new AST compiler Message-ID: Bugs item #1333982, was opened at 2005-10-21 03:08 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: AST >Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Armin Rigo (arigo) Assigned to: Neal Norwitz (nnorwitz) Summary: Bugs of the new AST compiler Initial Comment: The newly merged AST branch is likely to expose a number of small problems before it stabilizes, so here is a tentative bug tracker entry to collect such small problems. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-03 22:10 Message: Logged In: YES user_id=33168 I believe this addresses all the bugs. If you find new bugs, please open a new report so it's easier to track. Committed revision 51081. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-03 00:26 Message: Logged In: YES user_id=33168 Fix pending. need tests and code to be thawed. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2006-07-09 14:23 Message: Logged In: YES user_id=35752 Unary minus bug has been fixed in SVN rev 50495. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2006-07-09 14:05 Message: Logged In: YES user_id=35752 Regarding the -2147483648 bug: the old compiler tries to fold unary +, - and ~ if the RHS is a constant. I think only the minus case is important since the others are just optimizations, right? Attaching what seems to be a minimum fix. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-02 04:29 Message: Logged In: YES user_id=4771 Attached a patch for the LOAD_CONST POP_TOP optimization (modified from Georg Brandl on python-dev). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-04-11 02:41 Message: Logged In: YES user_id=6656 Good morning Armin! I've reported that bug already: http://python.org/sf/1441486 There's a patch which purports to fix it: http://python.org/sf/1446922 but I haven't gotten around to testing it. (this is running the pypy/module/array tests or something, isn't it?) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-04-11 01:45 Message: Logged In: YES user_id=4771 Another one: the literal -2147483648 (i.e. the value of -sys.maxint-1) gives a long in 2.5, but an int in <= 2.4. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-03 00:30 Message: Logged In: YES user_id=33168 The tuple store problem is fixed. The only outstanding item is the LOAD_CONST/POP_TOP. I will fix that soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-17 22:56 Message: Logged In: YES user_id=33168 Jeremy, there's no need to read anything before my last comment at 2005-12-17 23:10. The last two by Armin, Michael, then my last comment are the only important ones. Everything that occurred before my 2005-12-17 comment was taken care of AFAIK. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-02-12 13:54 Message: Logged In: YES user_id=4771 Subscripting is generally a bit sloppy: e.g. the AST model has no way to distinguish between a single value and a one-element tuple value! See: >>> d = {} >>> d[1,] = 6 >>> d {1: 6} # ! I suggest we fix the model to turn the 'subs' of the 'Subscript' node from a list of nodes to a single, mandatory 'sub' node. If tupling is necessary, it can be explicitly represented with a 'sub' containing a 'Tuple' node. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-02-09 07:02 Message: Logged In: YES user_id=6656 We found another one. Something is wrong in the compilation of augmented assignment to subscriptions containing tuples; running this code: class C: def __setitem__(self, i, v): print i, v def __getitem__(self, i): print i return 0 c = C() c[4,5] += 1 gives a spurious exception: Traceback (most recent call last): File "", line 1, in TypeError: object does not support item assignment By contrast, "c[(4,5)] += 1" works fine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-17 23:10 Message: Logged In: YES user_id=33168 EXTENDED_ARG problem was fixed a while ago. The assert/pass problem was fixed with: 41756. That leaves the LOAD_CONST/POP_TOP optimization that was lost and one compiler warning: marshal_write_mod() not being used. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-10 16:41 Message: Logged In: YES user_id=6656 You have to include those lines in a source file. It still crashes for me. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-12-10 15:44 Message: Logged In: YES user_id=357491 I just checked Armin's problem code on rev. 41638 and it worked for me in the interpreter. You still having problems, Armin? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-04 02:30 Message: Logged In: YES user_id=4771 At rev 41584, the following code snippet triggers an assert if --with-pydebug is enabled: Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed ----------------------- assert 1, ([s for s in x] + [s for s in x]) pass ----------------------- ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-23 12:14 Message: Logged In: YES user_id=33168 Checkpoint of outstanding issues. I think all the others mentioned so far have been fixed: * Raymond's warnings in compile.c (unused locals are fixed) * EXTENDED_ARG problem * LOAD_CONST/POP_TOP (note we can fix this in the optimizer generally which would get rid of other useless code too) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-22 21:53 Message: Logged In: YES user_id=80475 FWIW, here are the warnings issued by my compiler: Python-ast.c C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2085) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2130) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2151) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2261) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2270) : warning C4101: 'i' : unreferenced local variable compile.c C:\py25\Python\compile.c(3782) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3802) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3806) : warning C4305: '=' : truncation from 'const int ' to 'char ' ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-22 00:28 Message: Logged In: YES user_id=33168 I assigned to Jeremy and Neil in the hopes they will see this message and know about these problems. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:45 Message: Logged In: YES user_id=4771 The following (similarly strange-looking) code snippets compiled successfully before, now they give SyntaxErrors: -------------------- def f(): class g: exec "hi" x -------------------- def f(x): class g: exec "hi" x -------------------- def f(): class g: from a import * x -------------------- def f(x): class g: from a import * x ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:33 Message: Logged In: YES user_id=4771 I would suspect the following one to be due to incorrect handling of EXTENDED_ARG -- it's from a PyPy test about that: longexpr = 'x = x or ' + '-x' * 2500 code = ''' def f(x): %s %s %s %s %s %s %s %s %s %s while x: x -= 1 # EXTENDED_ARG/JUMP_ABSOLUTE here return x ''' % ((longexpr,)*10) exec code f(5) SystemError: unknown opcode dis.dis() shows that the target of both the SETUP_LOOP and the JUMP_IF_FALSE at the start of the loop are wrong. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:15 Message: Logged In: YES user_id=4771 The Python rules about which names get mangled are a bit insane. I share mwh's view that mangling should never have been invented in the first place, but well: >>> def f(): ... __x = 5 ... class X: ... def g(self): ... return __x ... return X ... Fatal Python error: unknown scope for _X__x in X(135832776) in ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 05:01 Message: Logged In: YES user_id=4771 For reference, an optimization that got lost: def f(): 'a' 'b' 'a' is the docstring, but the 'b' previously did not show up anywhere in the code object. Now there is the LOAD_CONST/POP_TOP pair. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 04:54 Message: Logged In: YES user_id=4771 any reason why lambda functions have a __name__ of 'lambda' now instead of '' ? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 03:22 Message: Logged In: YES user_id=4771 import a as b, c the 'c' part gets completely forgotten and there is no 'IMPORT_NAME c' in the bytecode. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 03:13 Message: Logged In: YES user_id=4771 A scoping problem (comparing with the old compiler): class X: print hello The variable 'hello' is incorrectly looked up with LOAD_GLOBAL instead of LOAD_NAME. It causes a crash in PyPy in a case where the name 'hello' is stored into the class implicitely (via locals()). It can probably be discussed if the bug is in PyPy, but it is a difference in behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 From noreply at sourceforge.net Fri Aug 4 07:18:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 22:18:19 -0700 Subject: [ python-Bugs-1531003 ] __weaklist__ in typeobject.c Message-ID: Bugs item #1531003, was opened at 2006-07-29 15:57 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531003&group_id=5470 Please note that this 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: Fred L. Drake, Jr. (fdrake) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: __weaklist__ in typeobject.c Initial Comment: typeobject.c:subtype_getweakref mentions __weaklist__ in an exception message that looks like it should refer to __weakref__. This exists in both 2.4 and the trunk. Fixing this should be just a matter of changing the message text; I don't see any other references to __weaklist__. ---------------------------------------------------------------------- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2006-08-04 01:18 Message: Logged In: YES user_id=3066 Corresponding patch committed for the Python trunk (2.5; revision 51084), and the release24-maint branch (2.4.4; revision 51083). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-03 23:45 Message: Logged In: YES user_id=33168 See patch 1534048 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531003&group_id=5470 From noreply at sourceforge.net Fri Aug 4 07:27:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 22:27:46 -0700 Subject: [ python-Bugs-1526585 ] Concatenation on a long string breaks Message-ID: Bugs item #1526585, was opened at 2006-07-21 10:18 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Jp Calderone (kuran) Assigned to: Armin Rigo (arigo) Summary: Concatenation on a long string breaks Initial Comment: Consider this transcript: exarkun at charm:~/Projects/python/trunk$ ./python Python 2.5b2 (trunk:50698, Jul 18 2006, 10:08:36) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> x = 'x' * (2 ** 31 - 1) >>> x = x + 'x' Traceback (most recent call last): File "", line 1, in SystemError: Objects/stringobject.c:4103: bad argument to internal function >>> len(x) Traceback (most recent call last): File "", line 1, in NameError: name 'x' is not defined >>> I would expect some exception other than SystemError and for the locals namespace to not become corrupted. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-03 22:27 Message: Logged In: YES user_id=33168 Armin, yes that sounds reasonable. Please checkin as soon as possible now that the trunk is not frozen. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-27 01:48 Message: Logged In: YES user_id=4771 Almost missed kuran's note. Kuran: I suppose you meant to use 2**31 instead of 2**32, but you've found another important bug: >>> s = 'x' * (2**32-2) >>> N = len(s) >>> N 2147483647 >>> 2**32 4294967296L Argh! Another check is missing somewhere. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-27 01:38 Message: Logged In: YES user_id=4771 We could reuse the --memlimit option of regrtest in the following way: At the moment it makes no sense to specify a --memlimit larger than Py_ssize_t, like 3GB on 32-bit systems. At least test_bigmem fails completely in this case. From this it seems that the --memlimit actually tells, more precisely, how much of its *address space* the Python test process is allowed to consume. So the value should be clamped to a maximum of MAX(Py_ssize_t). This would solve the current test_bigmem issue. If we do so, then the condition "--memlimit >= MAX(Py_ssize_t)" is precisely what should be checked to know if we can run the test for the bug in the present tracker, and other tests of the same kind, which check what occurs when the *address space* is exhausted. In this way, specifying --memlimit=3G would enable either test_bigmem (on 64-bit systems) or some new test_filladdressspace (on 32-bit systems), as appropriate. Sounds reasonable? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-26 08:50 Message: Logged In: YES user_id=33168 You're correct that bigmem is primarily for testing int/Py_ssize_t. But it doesn't have to be. It has support for machines with largish amounts of memory (and limiting test runs). I didn't know where else to put such a test. I agree that this bug would only occur on 32-bit platforms. Most machines can't run it, so about the only other option I can think of would be to put it in it's own file and add a -u option. That seemed like even more work. I'm not tied to bigmem at all, but it would be nice to have a test for this somewhere. I'm sure there are a bunch of other places we have this sort of overflow and it would be good to test them somewhere. Do whatever you think is best. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-26 02:01 Message: Logged In: YES user_id=4771 I'm unsure about how the bigmem tests should be used. I think that I am not supposed to set a >2G limit on a 32-bit machine, right? When I do, I get 9 failures: 8 OverflowErrors and a stranger AssertionError in test_hash. I think that these tests are meant to test the int/Py_ssize_t difference on 64-bit machines instead. The bug this tracker is about only shows up on 32-bit machines. My concern is that if we add a test for the current bug in test_bigmem, then with a memory limit < 2GB the test is essentially skipped, and with a memory limit > 2GB then 9 other tests fail anyway. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-25 21:19 Message: Logged In: YES user_id=33168 Armin, can you check in your patch and backport? Also a news entry and a test in test_bigmem would be great. Thanks. If not let me know (assign to me) and I'll finish this up. This fix should be backported as well. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-07-25 13:06 Message: Logged In: YES user_id=366566 Tested Armin's patch, looks like it addresses the issue. One thing I noticed though, ('x' * (2 ** 32 - 2) + 'x') fails the same way ('x' * (2 ** 32 - 1) + 'x'). Don't really understand why, just thought I'd mention it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-25 11:25 Message: Logged In: YES user_id=4771 The check should be done before the variable is removed from the namespace, so that 'x' doesn't just disappear. Attached a patch that does this. Also, let's produce an exception consistent with what PyString_Concat() raises in the same case, which is an OverflowError instead of a MemoryError. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-24 20:57 Message: Logged In: YES user_id=31435 [Neal] > Tim since we know both lens are >= 0, is this test > sufficient for verifying overflow: > > Py_ssize_t new_len = v_len + w_len; > if (new_len < 0) { Right! That's all the new checking needed in string_concatenate(). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-24 20:46 Message: Logged In: YES user_id=33168 Attached a patch against 2.5. The patch should work against 2.4 too, but you will need to change all Py_ssize_t to int. Tim since we know both lens are >= 0, is this test sufficient for verifying overflow: Py_ssize_t new_len = v_len + w_len; if (new_len < 0) { Jp, can you test the patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-22 07:11 Message: Logged In: YES user_id=31435 Part of the problem appears to be that ceval.c's string_concatenate() doesn't check for overflow in the second argument here: if (_PyString_Resize(&v, v_len + w_len) != 0) The Windows malloc on my box returns NULL (and so Python raises MemoryError) on the initial: x = 'x' * (2 ** 31 - 1) attempt, so I never get that far. I'm afraid this is muddier in strange ways on Linux because the Linux malloc() is pathologically optimistic (can return a non-NULL value pointing at "memory" that can't actually be used for anything). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-07-22 02:00 Message: Logged In: YES user_id=6656 Confirmed with 2.4. Ouch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470 From noreply at sourceforge.net Fri Aug 4 07:34:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Aug 2006 22:34:45 -0700 Subject: [ python-Bugs-1019808 ] wrong socket error returned Message-ID: Bugs item #1019808, was opened at 2004-08-31 09:18 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 Please note that this 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: Federico Schwindt (fgsch) >Assigned to: A.M. Kuchling (akuchling) Summary: wrong socket error returned Initial Comment: hi, first, background: OS: OpenBSD-current/i386 Python version: 2.3.4 example script: import socket socket.setdefaulttimeout(30) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1', 9999)) where nothing is listening on 9999 (ECONNREFUSED should be returned). when ran it i get: Traceback (most recent call last): File "bug.py", line 8, in ? s.connect(('127.0.0.1', 9999)) File "", line 1, in connect socket.error: (22, 'Invalid argument') this is a problem in the socketmodule.c, in the internal_connect() function. getsockopt with SOCK_ERROR should be used once EINPROGRESS is returned to get the real error. this code works on linux, but the connect semantic is, imho, broken. you cannot reuse a socket once it failed (a test afterwards shown that this is valid under linux!!!!). please contact me if you need further details, although i find this very clear. thanks, f.- ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-03 22:34 Message: Logged In: YES user_id=33168 Andrew, I'm ok with this patch, but not enthusiastic for 2.5. It might be better to wait for 2.5.1 in order to give this more time to settle. I agree that this change *should* be correct, but who knows if it will break some other platform(s). I leave it to you whether to apply for 2.5 or 2.5.1. It would be good to actually test this condition too. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 07:31 Message: Logged In: YES user_id=11375 Deleting broken patches; attaching a correct version against 2.5 trunk. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 07:18 Message: Logged In: YES user_id=11375 I can confirm the bug on MacOS X, and the failure of the patch to fix it. I think the logic of the patch is wrong; it saves errno in save_errno when errno==EINPROGRESS, does a getsockopt(), and then resets errno to save_errno, which we know is EINPROGRESS. I think the correct action is to do 'errno = ". Revised patch attached; it produces the correct result on OS X. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 07:15 Message: Logged In: YES user_id=11375 I can confirm the bug on MacOS X, and the failure of the patch to fix it. I think the logic of the patch is wrong; it saves errno in save_errno when errno==EINPROGRESS, does a getsockopt(), and then resets errno to save_errno, which we know is EINPROGRESS. I think the correct action is to do 'errno = ". Revised patch attached; it produces the correct result on OS X. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 07:14 Message: Logged In: YES user_id=11375 I can confirm the bug on MacOS X, and the failure of the patch to fix it. I think the logic of the patch is wrong; it saves errno in save_errno when errno==EINPROGRESS, does a getsockopt(), and then resets errno to save_errno, which we know is EINPROGRESS. I think the correct action is to do 'errno = ". Revised patch attached; it produces the correct result on OS X. ---------------------------------------------------------------------- Comment By: Frank Vercruesse (vercruesse) Date: 2006-02-17 12:46 Message: Logged In: YES user_id=202246 I can confirm the bug running Python 2.4.2 on Mac OS X 10.4.5 (PPC). However, the patch doesn't seem to resolve the issue. Now I get the following traceback when running the posted script: Traceback (most recent call last): File "", line 1, in ? File "", line 1, in connect socket.error: (36, 'Operation now in progress') ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2005-10-03 12:44 Message: Logged In: YES user_id=50493 patch against 2.4.1 appended. not tested in anything but openbsd. nevertheless, i think it should work in linux and osx. not sure about others. cheers. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 23:02 Message: Logged In: YES user_id=33168 Can you provide a patch that you believe corrects this problem? ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2005-06-24 02:41 Message: Logged In: YES user_id=50493 just tried this with 2.4.1 running in OpenBSD 3.7/amd64 and the problem is still there :-( ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2004-09-22 20:58 Message: Logged In: YES user_id=50493 any news? this may be a problem in other *BSDs as well.. ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2004-08-31 09:22 Message: Logged In: YES user_id=50493 maybe i was not clear. the problem is only happening when setdefaulttimeout is used. otherwise ECONNREFUSED is correctly returned. f.- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 From noreply at sourceforge.net Fri Aug 4 15:04:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 06:04:37 -0700 Subject: [ python-Bugs-1534517 ] getlines() in linecache.py raises TypeError Message-ID: Bugs item #1534517, was opened at 2006-08-04 15: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=1534517&group_id=5470 Please note that this 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: Stefan Behnel (scoder) Assigned to: Nobody/Anonymous (nobody) Summary: getlines() in linecache.py raises TypeError Initial Comment: In my doctests, I get the following error under 2.5. I'm on AMD64 in case that's of any interest. Traceback (most recent call last): File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/unittest.py", line 260, in run testMethod() File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 2182, in runTest test, out=new.write, clear_globs=False) File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 1389, in run return self.__run(test, compileflags, out) File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 1280, in __run got += _exception_traceback(exc_info) File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 257, in _exception_traceback traceback.print_exception(exc_type, exc_val, exc_tb, file=excout) File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/traceback.py", line 125, in print_exception print_tb(tb, limit, file) File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/traceback.py", line 69, in print_tb line = linecache.getline(filename, lineno, f.f_globals) File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/linecache.py", line 14, in getline lines = getlines(filename, module_globals) TypeError: __patched_linecache_getlines() takes exactly 2 arguments (3 given) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534517&group_id=5470 From noreply at sourceforge.net Fri Aug 4 15:21:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 06:21:00 -0700 Subject: [ python-Bugs-1467929 ] %-formatting and dicts Message-ID: Bugs item #1467929, was opened at 2006-04-10 14:39 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Anthony Baxter (anthonybaxter) Summary: %-formatting and dicts Initial Comment: This looks like a bug in the way the %-formatting code works or is it a feature ? >>> '%s %(a)s' % {'a': 'xyz'} "{'a': 'xyz'} xyz" >>> u'%s %(a)s' % {'a': 'xyz'} u"{'a': 'xyz'} xyz" Note that both strings and Unicode are affected. Python 2.3 and 2.4 also show this behavior. I would have expected an exception or the %-formatter simply ignoring the first %s. ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2006-08-04 08:21 Message: Logged In: YES user_id=44345 Looks okay to me, though why is the FORMAT_TYPE_UNKNOWN test necessary in the second case but not the first? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-07-25 07:35 Message: Logged In: YES user_id=11375 So, what should '%s' % {} do? Should it be 1) '{}' or 2) an error because the argument is a mapping but the format specifier doesn't have a '(key)'? I've attached a draft patch that fixes stringobject.c; if the approach is deemed OK, I'll apply it to unicodeobject.c, too. PyString_Format() records the type of argument being processed (a tuple or a mapping) and raises ValueError if you mix them, at the cost of two extra comparisons for each format specifier processed. This preserves the current behaviour of '%s' % dictionary. Questions: 1) is the approach reasonably clear? 2) are the additional two comparisons unacceptably slow? 3) Is ValueError the right exception? 4) can someone come up with a better exception message than "both keyed and unkeyed format specifiers used"? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-07-24 15:07 Message: Logged In: YES user_id=21627 IMO, it's correct to break backwards compatibility, as the current behaviour clearly violates the spec; I'm not sure whether it's good to break the behaviour *now* (i.e. with no further betas before the release of 2.5). Deferring to the release manager. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 08:37 Message: Logged In: YES user_id=849994 The library ref specifies that if a dict is supplied, the format specifiers MUST include a mapping key, so the right thing to do would be to raise an exception. Is it worth breaking backwards compatibility, Martin? ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2006-04-14 03:33 Message: Logged In: YES user_id=1185570 It looks as though it's a feature... The first %s will print the whole dictionary as a string, the second, only that value looked up by the key. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470 From noreply at sourceforge.net Fri Aug 4 15:26:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 06:26:47 -0700 Subject: [ python-Bugs-1467929 ] %-formatting and dicts Message-ID: Bugs item #1467929, was opened at 2006-04-10 21:39 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Anthony Baxter (anthonybaxter) Summary: %-formatting and dicts Initial Comment: This looks like a bug in the way the %-formatting code works or is it a feature ? >>> '%s %(a)s' % {'a': 'xyz'} "{'a': 'xyz'} xyz" >>> u'%s %(a)s' % {'a': 'xyz'} u"{'a': 'xyz'} xyz" Note that both strings and Unicode are affected. Python 2.3 and 2.4 also show this behavior. I would have expected an exception or the %-formatter simply ignoring the first %s. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-04 15:26 Message: Logged In: YES user_id=38388 The patch looks OK. I'd make it a TypeError and use "cannot use positional and named formatting parameters at the same time" as message. Thanks. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-04 15:21 Message: Logged In: YES user_id=44345 Looks okay to me, though why is the FORMAT_TYPE_UNKNOWN test necessary in the second case but not the first? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-07-25 14:35 Message: Logged In: YES user_id=11375 So, what should '%s' % {} do? Should it be 1) '{}' or 2) an error because the argument is a mapping but the format specifier doesn't have a '(key)'? I've attached a draft patch that fixes stringobject.c; if the approach is deemed OK, I'll apply it to unicodeobject.c, too. PyString_Format() records the type of argument being processed (a tuple or a mapping) and raises ValueError if you mix them, at the cost of two extra comparisons for each format specifier processed. This preserves the current behaviour of '%s' % dictionary. Questions: 1) is the approach reasonably clear? 2) are the additional two comparisons unacceptably slow? 3) Is ValueError the right exception? 4) can someone come up with a better exception message than "both keyed and unkeyed format specifiers used"? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-07-24 22:07 Message: Logged In: YES user_id=21627 IMO, it's correct to break backwards compatibility, as the current behaviour clearly violates the spec; I'm not sure whether it's good to break the behaviour *now* (i.e. with no further betas before the release of 2.5). Deferring to the release manager. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 15:37 Message: Logged In: YES user_id=849994 The library ref specifies that if a dict is supplied, the format specifiers MUST include a mapping key, so the right thing to do would be to raise an exception. Is it worth breaking backwards compatibility, Martin? ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2006-04-14 10:33 Message: Logged In: YES user_id=1185570 It looks as though it's a feature... The first %s will print the whole dictionary as a string, the second, only that value looked up by the key. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470 From noreply at sourceforge.net Fri Aug 4 15:30:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 06:30:56 -0700 Subject: [ python-Bugs-1534517 ] getlines() in linecache.py raises TypeError Message-ID: Bugs item #1534517, was opened at 2006-08-04 15:04 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534517&group_id=5470 Please note that this 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: Stefan Behnel (scoder) Assigned to: Nobody/Anonymous (nobody) Summary: getlines() in linecache.py raises TypeError Initial Comment: In my doctests, I get the following error under 2.5. I'm on AMD64 in case that's of any interest. Traceback (most recent call last): File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/unittest.py", line 260, in run testMethod() File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 2182, in runTest test, out=new.write, clear_globs=False) File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 1389, in run return self.__run(test, compileflags, out) File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 1280, in __run got += _exception_traceback(exc_info) File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 257, in _exception_traceback traceback.print_exception(exc_type, exc_val, exc_tb, file=excout) File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/traceback.py", line 125, in print_exception print_tb(tb, limit, file) File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/traceback.py", line 69, in print_tb line = linecache.getline(filename, lineno, f.f_globals) File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/linecache.py", line 14, in getline lines = getlines(filename, module_globals) TypeError: __patched_linecache_getlines() takes exactly 2 arguments (3 given) ---------------------------------------------------------------------- Comment By: Žiga Seilnacht (zseil) Date: 2006-08-04 15:30 Message: Logged In: YES user_id=1326842 This bug is caused by your custom doctest module. Doctest monkeypatches linecache's getlines() function. It was fixed in the standard library to support an aditional argument, but it looks that lxml is still using the 2.4 version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534517&group_id=5470 From noreply at sourceforge.net Fri Aug 4 16:06:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 07:06:00 -0700 Subject: [ python-Bugs-1534517 ] getlines() in linecache.py raises TypeError Message-ID: Bugs item #1534517, was opened at 2006-08-04 15:04 Message generated for change (Comment added) made by scoder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534517&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Stefan Behnel (scoder) Assigned to: Nobody/Anonymous (nobody) Summary: getlines() in linecache.py raises TypeError Initial Comment: In my doctests, I get the following error under 2.5. I'm on AMD64 in case that's of any interest. Traceback (most recent call last): File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/unittest.py", line 260, in run testMethod() File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 2182, in runTest test, out=new.write, clear_globs=False) File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 1389, in run return self.__run(test, compileflags, out) File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 1280, in __run got += _exception_traceback(exc_info) File "/home/me/source/Python/lxml/lxml-HEAD/src/doctest.py", line 257, in _exception_traceback traceback.print_exception(exc_type, exc_val, exc_tb, file=excout) File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/traceback.py", line 125, in print_exception print_tb(tb, limit, file) File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/traceback.py", line 69, in print_tb line = linecache.getline(filename, lineno, f.f_globals) File "/var/tmp/python2.5-2.5b3-root/usr/lib64/python2.5/linecache.py", line 14, in getline lines = getlines(filename, module_globals) TypeError: __patched_linecache_getlines() takes exactly 2 arguments (3 given) ---------------------------------------------------------------------- >Comment By: Stefan Behnel (scoder) Date: 2006-08-04 16:06 Message: Logged In: YES user_id=313935 Argh! Sure. I only saw "doctest" and "linecache" and didn't even notice it was using the local file. No idea why it's there anyway. Thanks! Great time to close this 'bug' ... ---------------------------------------------------------------------- Comment By: Žiga Seilnacht (zseil) Date: 2006-08-04 15:30 Message: Logged In: YES user_id=1326842 This bug is caused by your custom doctest module. Doctest monkeypatches linecache's getlines() function. It was fixed in the standard library to support an aditional argument, but it looks that lxml is still using the 2.4 version. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534517&group_id=5470 From noreply at sourceforge.net Fri Aug 4 16:40:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 07:40:26 -0700 Subject: [ python-Feature Requests-1534607 ] IndexError: Add bad index to msg Message-ID: Feature Requests item #1534607, was opened at 2006-08-04 09:40 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=1534607&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Submitted By: Michael Kleehammer (mkleehammer) Assigned to: Nobody/Anonymous (nobody) Summary: IndexError: Add bad index to msg Initial Comment: It would be very helpful to add more information to the IndexErrors raised by the built-in classes. Today, these errors look like: IndexError: list index out of range When these occur, I usually have to add print statements before the error and reproduce the problem to determine what has gone wrong. If the list and tuple classes add the requested index and the length of the structure, it would help a lot. Below is a suggestion: IndexError: list index 30 out of range; len=27 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1534607&group_id=5470 From noreply at sourceforge.net Fri Aug 4 17:29:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 08:29:11 -0700 Subject: [ python-Bugs-1534630 ] Python 2.5 svn crash in _elementtree.c Message-ID: Bugs item #1534630, was opened at 2006-08-04 11:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 9 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fredrik Lundh (effbot) Summary: Python 2.5 svn crash in _elementtree.c Initial Comment: /F's sourceforge screen scraper tool triggered a crash in _elementtree.c in the latest Python 2.5 svn. It seems that a Py_DECREF should probably be a Py_XDECREF unless there's some other logic bug I'm missing. Here's the patch if it's the former. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&group_id=5470 From noreply at sourceforge.net Fri Aug 4 20:29:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 11:29:50 -0700 Subject: [ python-Bugs-1530448 ] ctypes build fails on Solaris 10 Message-ID: Bugs item #1530448, was opened at 2006-07-28 17:04 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-08-04 20:29 Message: Logged In: YES user_id=11105 Yes, the patch was supposed to be applied to the top-level setup.py script, in the same directory as the README and the LICENSE files. If you applied the patch, and '-mimpure-text' does not appear on the linker command line (for me, it appears at the very end), the only explanation I see is that sys.platform == "sunos5" is not true on your system. Can that be? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 22:37 Message: Logged In: YES user_id=44345 make that "_ctypes.so"... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 22:14 Message: Logged In: YES user_id=44345 When I manually link _ctypes.o with -mimpure-text the link succeeds, but applying it to the configure script had no discernable effect. Was I supposed to apply it to the top-level Python configure script or to one deeper in the tree? Skip ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 22:02 Message: Logged In: YES user_id=44345 Thomas, I did an svn up (rev 51078), deleted any local changes, created a new build directory, configured and built. I got the same error about ffi_closure_SYSV_inner. I then manually reran the link command without mention of ffi.o or sysv.o. It linked fine but when I ran make again it complained that _ctypes.so couldn't resolve ffi_prep_closure. This symbol is defined in ffi.o, so it appears either that ffi.c is needed in the source list or maybe ffi64.c needs to be modified to provide it. As far as I can tell it doesn't export any useful symbols: $ nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 f ffi64.c Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 21:36 Message: Logged In: YES user_id=11105 Correction: The option is '-mimpure-text', not '-impure-text'. I've attached a new patch 'setup.py.patch' which allows to build on the sourceforge solaris-x86 machine. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 21:28 Message: Logged In: YES user_id=11105 And, BTW, building the bz2 extension on the compile farm solaris-x86 machine also fails with relocation errors (but I have no idea if that is related to the _ctypes build failure or not). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 21:24 Message: Logged In: YES user_id=11105 What I've found out, after some painful time on the sourceforge compilefarm, is this: Python svn trunk also fails to build _ctypes.so on the solaris-x86 machine, but not on the sparc machines (both have solaris 9, I believe). ctypes from svn trunk *does* build also on the x86 machine, with the system installed python2.3, also with python 2.5b2. One difference that I found is that ctypes svn setup.py passes '-impure-text' to the linker, while python svn (when building the bundled ctypes) does not. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-02 15:20 Message: Logged In: YES user_id=11105 It seems that the files 'src/x86/ffi.c' and 'src/x86/sysv.S' are not needed for the X86_64 platform in fficonfig.py.in. They *should* compile to nothing, anyway, because their contents is protected by 'ifndef __x86_64__'. Does removing them from fficonfig.py.in change the situation, so that only this remains: 'X86_64': ['src/x86/ffi64.c', 'src/x86/unix64.S'], I can build _ctypes on an unbuntu amd64 system with this change. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-02 15:08 Message: Logged In: YES user_id=44345 I don't understand. I swapped the order of ffi.c and sysv.S in the platforms dict. I confirmed that the order of the .o files on the link line changed so that ffi.o followed sysv.o. I still get the same error. I've also confirmed that ffi.o exports the symbol and that sysv.o references it: % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 U _GLOBAL_OFFSET_TABLE_ 0000000000 f ffi.c 0000000332 T ffi_call 0000000000 U ffi_call_SYSV 0000000000 U ffi_closure_SYSV 0000000456 T ffi_closure_SYSV_inner 0000000000 T ffi_prep_args 0000000252 T ffi_prep_cif_machdep 0000000612 T ffi_prep_closure 0000000000 U memcpy % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000109 n epilogue 0000000000 T ffi_call_SYSV 0000000116 T ffi_closure_SYSV 0000000000 U ffi_closure_SYSV_inner 0000000000 U ffi_prep_args 0000000109 n noretval 0000000071 n retdouble 0000000059 n retfloat 0000000046 n retint 0000000095 n retint64 0000000083 n retlongdouble 0000000109 n retstruct All the object files were compiled with -fPIC. Here's the relevant chunk of make's output: creating build/temp.solaris-2.10-i86pc-2.5/libffi checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for gcc... /opt/app/g++lib6/gcc-3.4/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /opt/app/g++lib6/gcc-3.4/bin/gcc accepts -g... yes checking for /opt/app/g++lib6/gcc-3.4/bin/gcc option to accept ANSI C... none needed checking how to run the C preprocessor... /opt/app/g++lib6/gcc-3.4/bin/gcc -E checking for egrep... egrep checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking sys/mman.h usability... yes checking sys/mman.h presence... yes checking for sys/mman.h... yes checking for mmap... yes checking for sys/mman.h... (cached) yes checking for mmap... (cached) yes checking whether read-only mmap of a plain file works... yes checking whether mmap from /dev/zero works... yes checking for MAP_ANON(YMOUS)... yes checking whether mmap with MAP_ANON(YMOUS) works... yes checking for ANSI C header files... (cached) yes checking for memcpy... yes checking for working alloca.h... yes checking for alloca... yes checking for double... yes checking size of double... 8 checking for long double... yes checking size of long double... 12 checking whether byte ordering is bigendian... no checking whether .eh_frame section should be read-only... no checking for __attribute__((visibility("hidden")))... no configure: creating ./config.status config.status: creating include/ffi.h config.status: creating fficonfig.py config.status: creating fficonfig.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffitarget.h to include/ffitarget.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/include/ffi_common.h to include/ffi_common.h config.status: executing include commands config.status: executing src commands >>> X86_64 ['src/prep_cif.c', 'src/x86/ffi64.c', 'src/x86/unix64.S', 'src/x86/sysv.S', 'src/x86/ffi.c'] building '_ctypes' extension /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c: In function `_CallProc': /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c:917: warning: implicit declaration of function `alloca' /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:177: warning: function declaration isn't a prototype /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:194: warning: function declaration isn't a prototype /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I added a couple prints to fficonfig.py.in to demonstrate the file order and platform name (and to make sure fficonfig.py was being rebuilt). Oddly enough, if I remove both ffi.o and sysv.o from the link line, it links successfully. Is that significant or am I just getting desparate? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-01 22:02 Message: Logged In: YES user_id=11105 I didn't know there are any systems that depend on the order of object files on the linker command line any more ;-). IIUC, the objects list is derived by distutils from the sources list, so the attached patch (for Modules/_ctypes/libffi/fficonfig.py.in) *could* do the trick. Please make sure that fficonfig.py is recreated (by doing make clean before building or whatever). Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-01 18:16 Message: Logged In: YES user_id=44345 Thomas> Skip, do you have *any* idea what might be Thomas> wrong, or could you even come up with a patch? Skip> I've no idea so far. I'll try to find some time Skip> to take a look at it later today. Thomas, Sorry for the delay. I think I have it figured out and it was fairly straightforward. Looking at the files in order on the _ctypes.so link line we see that the definition of ffi_closure_SYSV_inner is defined before it's referenced: for obj in build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ; do echo $obj; nm -p $obj | egrep ffi_closure_SYSV_inner; done build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o 0000000456 T ffi_closure_SYSV_inner build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o 0000000000 U ffi_closure_SYSV_inner Since we're linking from object files, it's a one-pass link algorithm. At the time ffo.o is examined, sysv.o hasn't been seen. Consequently, ffi_closure_SYSV_inner is not yet known and its definition isn't picked up from ffi.o. I couldn't quickly figure out where the link command is generated, but I'm sure you'll know where it resides. Either swap ffi.o and sysv.o on the link line, or add ffi.o a second time to resolve the new reference. Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-31 12:54 Message: Logged In: YES user_id=11105 Skip, do you have *any* idea what might be wrong, or could you even come up with a patch? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-07-29 00:03 Message: Logged In: YES user_id=44345 Yeah, you'd definitely need -fPIC on any brand of Solaris. That test might be changed to plat = get_platform() if plat in (... buncha platforms ...) or "solaris" in plat: os.environ["CFLAGS"] = "-fPIC" That doesn't seem to be what's happening in this case though. I rm'd the .o files in .../Modules/_ctypes and tried again. The compile commands *do* have -fPIC on them. I don't think it's required on the link line. S ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-28 18:19 Message: Logged In: YES user_id=11105 Skip, This looks *somewhat* like the problems reported in bugs 1529269 and 1528620 (although they have a sparc, and you seem to have x86 solaris). Hm, in the standalone ctypes setup script, I find this code snippet: if get_platform() in ["solaris-2.9-sun4u", "linux-x86_64"]: os.environ["CFLAGS"] = "-fPIC" Can it be that -fPIC must be used, but is not specified? It is also funny that the solaris buildbot does NOT seem to have a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 From noreply at sourceforge.net Fri Aug 4 20:44:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 11:44:36 -0700 Subject: [ python-Bugs-1530448 ] ctypes build fails on Solaris 10 Message-ID: Bugs item #1530448, was opened at 2006-07-28 10:04 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2006-08-04 13:44 Message: Logged In: YES user_id=44345 It turned out to be a patch problem (something I've never encountered before): % patch -p0 < /home/titan/skipm/Desktop/setup.py\(2\).patch patching file setup.py Hunk #2 succeeded at 1361 with fuzz 2. I tried deleting setup.py, svn up'ing and reapplying the patch a couple other times. When I manually compared the new setup.py with the diff file I saw that the stuff below the "Is this still needed?" line wasn't actually applied. I manually updated setup.py from the diff file (good thing it was a simple diff!) It now builds properly. Thanks for all the work you put into this, Thomas. Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-04 13:29 Message: Logged In: YES user_id=11105 Yes, the patch was supposed to be applied to the top-level setup.py script, in the same directory as the README and the LICENSE files. If you applied the patch, and '-mimpure-text' does not appear on the linker command line (for me, it appears at the very end), the only explanation I see is that sys.platform == "sunos5" is not true on your system. Can that be? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 15:37 Message: Logged In: YES user_id=44345 make that "_ctypes.so"... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 15:14 Message: Logged In: YES user_id=44345 When I manually link _ctypes.o with -mimpure-text the link succeeds, but applying it to the configure script had no discernable effect. Was I supposed to apply it to the top-level Python configure script or to one deeper in the tree? Skip ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 15:02 Message: Logged In: YES user_id=44345 Thomas, I did an svn up (rev 51078), deleted any local changes, created a new build directory, configured and built. I got the same error about ffi_closure_SYSV_inner. I then manually reran the link command without mention of ffi.o or sysv.o. It linked fine but when I ran make again it complained that _ctypes.so couldn't resolve ffi_prep_closure. This symbol is defined in ffi.o, so it appears either that ffi.c is needed in the source list or maybe ffi64.c needs to be modified to provide it. As far as I can tell it doesn't export any useful symbols: $ nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 f ffi64.c Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 14:36 Message: Logged In: YES user_id=11105 Correction: The option is '-mimpure-text', not '-impure-text'. I've attached a new patch 'setup.py.patch' which allows to build on the sourceforge solaris-x86 machine. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 14:28 Message: Logged In: YES user_id=11105 And, BTW, building the bz2 extension on the compile farm solaris-x86 machine also fails with relocation errors (but I have no idea if that is related to the _ctypes build failure or not). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 14:24 Message: Logged In: YES user_id=11105 What I've found out, after some painful time on the sourceforge compilefarm, is this: Python svn trunk also fails to build _ctypes.so on the solaris-x86 machine, but not on the sparc machines (both have solaris 9, I believe). ctypes from svn trunk *does* build also on the x86 machine, with the system installed python2.3, also with python 2.5b2. One difference that I found is that ctypes svn setup.py passes '-impure-text' to the linker, while python svn (when building the bundled ctypes) does not. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-02 08:20 Message: Logged In: YES user_id=11105 It seems that the files 'src/x86/ffi.c' and 'src/x86/sysv.S' are not needed for the X86_64 platform in fficonfig.py.in. They *should* compile to nothing, anyway, because their contents is protected by 'ifndef __x86_64__'. Does removing them from fficonfig.py.in change the situation, so that only this remains: 'X86_64': ['src/x86/ffi64.c', 'src/x86/unix64.S'], I can build _ctypes on an unbuntu amd64 system with this change. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-02 08:08 Message: Logged In: YES user_id=44345 I don't understand. I swapped the order of ffi.c and sysv.S in the platforms dict. I confirmed that the order of the .o files on the link line changed so that ffi.o followed sysv.o. I still get the same error. I've also confirmed that ffi.o exports the symbol and that sysv.o references it: % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 U _GLOBAL_OFFSET_TABLE_ 0000000000 f ffi.c 0000000332 T ffi_call 0000000000 U ffi_call_SYSV 0000000000 U ffi_closure_SYSV 0000000456 T ffi_closure_SYSV_inner 0000000000 T ffi_prep_args 0000000252 T ffi_prep_cif_machdep 0000000612 T ffi_prep_closure 0000000000 U memcpy % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000109 n epilogue 0000000000 T ffi_call_SYSV 0000000116 T ffi_closure_SYSV 0000000000 U ffi_closure_SYSV_inner 0000000000 U ffi_prep_args 0000000109 n noretval 0000000071 n retdouble 0000000059 n retfloat 0000000046 n retint 0000000095 n retint64 0000000083 n retlongdouble 0000000109 n retstruct All the object files were compiled with -fPIC. Here's the relevant chunk of make's output: creating build/temp.solaris-2.10-i86pc-2.5/libffi checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for gcc... /opt/app/g++lib6/gcc-3.4/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /opt/app/g++lib6/gcc-3.4/bin/gcc accepts -g... yes checking for /opt/app/g++lib6/gcc-3.4/bin/gcc option to accept ANSI C... none needed checking how to run the C preprocessor... /opt/app/g++lib6/gcc-3.4/bin/gcc -E checking for egrep... egrep checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking sys/mman.h usability... yes checking sys/mman.h presence... yes checking for sys/mman.h... yes checking for mmap... yes checking for sys/mman.h... (cached) yes checking for mmap... (cached) yes checking whether read-only mmap of a plain file works... yes checking whether mmap from /dev/zero works... yes checking for MAP_ANON(YMOUS)... yes checking whether mmap with MAP_ANON(YMOUS) works... yes checking for ANSI C header files... (cached) yes checking for memcpy... yes checking for working alloca.h... yes checking for alloca... yes checking for double... yes checking size of double... 8 checking for long double... yes checking size of long double... 12 checking whether byte ordering is bigendian... no checking whether .eh_frame section should be read-only... no checking for __attribute__((visibility("hidden")))... no configure: creating ./config.status config.status: creating include/ffi.h config.status: creating fficonfig.py config.status: creating fficonfig.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffitarget.h to include/ffitarget.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/include/ffi_common.h to include/ffi_common.h config.status: executing include commands config.status: executing src commands >>> X86_64 ['src/prep_cif.c', 'src/x86/ffi64.c', 'src/x86/unix64.S', 'src/x86/sysv.S', 'src/x86/ffi.c'] building '_ctypes' extension /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c: In function `_CallProc': /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c:917: warning: implicit declaration of function `alloca' /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:177: warning: function declaration isn't a prototype /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:194: warning: function declaration isn't a prototype /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I added a couple prints to fficonfig.py.in to demonstrate the file order and platform name (and to make sure fficonfig.py was being rebuilt). Oddly enough, if I remove both ffi.o and sysv.o from the link line, it links successfully. Is that significant or am I just getting desparate? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-01 15:02 Message: Logged In: YES user_id=11105 I didn't know there are any systems that depend on the order of object files on the linker command line any more ;-). IIUC, the objects list is derived by distutils from the sources list, so the attached patch (for Modules/_ctypes/libffi/fficonfig.py.in) *could* do the trick. Please make sure that fficonfig.py is recreated (by doing make clean before building or whatever). Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-01 11:16 Message: Logged In: YES user_id=44345 Thomas> Skip, do you have *any* idea what might be Thomas> wrong, or could you even come up with a patch? Skip> I've no idea so far. I'll try to find some time Skip> to take a look at it later today. Thomas, Sorry for the delay. I think I have it figured out and it was fairly straightforward. Looking at the files in order on the _ctypes.so link line we see that the definition of ffi_closure_SYSV_inner is defined before it's referenced: for obj in build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ; do echo $obj; nm -p $obj | egrep ffi_closure_SYSV_inner; done build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o 0000000456 T ffi_closure_SYSV_inner build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o 0000000000 U ffi_closure_SYSV_inner Since we're linking from object files, it's a one-pass link algorithm. At the time ffo.o is examined, sysv.o hasn't been seen. Consequently, ffi_closure_SYSV_inner is not yet known and its definition isn't picked up from ffi.o. I couldn't quickly figure out where the link command is generated, but I'm sure you'll know where it resides. Either swap ffi.o and sysv.o on the link line, or add ffi.o a second time to resolve the new reference. Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-31 05:54 Message: Logged In: YES user_id=11105 Skip, do you have *any* idea what might be wrong, or could you even come up with a patch? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-07-28 17:03 Message: Logged In: YES user_id=44345 Yeah, you'd definitely need -fPIC on any brand of Solaris. That test might be changed to plat = get_platform() if plat in (... buncha platforms ...) or "solaris" in plat: os.environ["CFLAGS"] = "-fPIC" That doesn't seem to be what's happening in this case though. I rm'd the .o files in .../Modules/_ctypes and tried again. The compile commands *do* have -fPIC on them. I don't think it's required on the link line. S ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-28 11:19 Message: Logged In: YES user_id=11105 Skip, This looks *somewhat* like the problems reported in bugs 1529269 and 1528620 (although they have a sparc, and you seem to have x86 solaris). Hm, in the standalone ctypes setup script, I find this code snippet: if get_platform() in ["solaris-2.9-sun4u", "linux-x86_64"]: os.environ["CFLAGS"] = "-fPIC" Can it be that -fPIC must be used, but is not specified? It is also funny that the solaris buildbot does NOT seem to have a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 From noreply at sourceforge.net Fri Aug 4 20:58:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 11:58:39 -0700 Subject: [ python-Bugs-1530448 ] ctypes build fails on Solaris 10 Message-ID: Bugs item #1530448, was opened at 2006-07-28 17:04 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Thomas Heller (theller) Summary: ctypes build fails on Solaris 10 Initial Comment: Thomas, I tried to build Python from cvs (svn rev 50905) on Solaris 10 today. Compiler was gcc 3.4. I got a text relocation error when linking ctypes.so: /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I tried configuring both with and without the --with-system-ffi flag. The error was the same in both cases. If you need more information, let me know. Skip ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-08-04 20:58 Message: Logged In: YES user_id=11105 I apologize for the damaged patch - I could not apply it correctly either. Somehow an empty line made into it, or whatever. Thanks for testing! Committed as r51113. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-04 20:44 Message: Logged In: YES user_id=44345 It turned out to be a patch problem (something I've never encountered before): % patch -p0 < /home/titan/skipm/Desktop/setup.py\(2\).patch patching file setup.py Hunk #2 succeeded at 1361 with fuzz 2. I tried deleting setup.py, svn up'ing and reapplying the patch a couple other times. When I manually compared the new setup.py with the diff file I saw that the stuff below the "Is this still needed?" line wasn't actually applied. I manually updated setup.py from the diff file (good thing it was a simple diff!) It now builds properly. Thanks for all the work you put into this, Thomas. Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-04 20:29 Message: Logged In: YES user_id=11105 Yes, the patch was supposed to be applied to the top-level setup.py script, in the same directory as the README and the LICENSE files. If you applied the patch, and '-mimpure-text' does not appear on the linker command line (for me, it appears at the very end), the only explanation I see is that sys.platform == "sunos5" is not true on your system. Can that be? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 22:37 Message: Logged In: YES user_id=44345 make that "_ctypes.so"... ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 22:14 Message: Logged In: YES user_id=44345 When I manually link _ctypes.o with -mimpure-text the link succeeds, but applying it to the configure script had no discernable effect. Was I supposed to apply it to the top-level Python configure script or to one deeper in the tree? Skip ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-03 22:02 Message: Logged In: YES user_id=44345 Thomas, I did an svn up (rev 51078), deleted any local changes, created a new build directory, configured and built. I got the same error about ffi_closure_SYSV_inner. I then manually reran the link command without mention of ffi.o or sysv.o. It linked fine but when I ran make again it complained that _ctypes.so couldn't resolve ffi_prep_closure. This symbol is defined in ffi.o, so it appears either that ffi.c is needed in the source list or maybe ffi64.c needs to be modified to provide it. As far as I can tell it doesn't export any useful symbols: $ nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 f ffi64.c Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 21:36 Message: Logged In: YES user_id=11105 Correction: The option is '-mimpure-text', not '-impure-text'. I've attached a new patch 'setup.py.patch' which allows to build on the sourceforge solaris-x86 machine. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 21:28 Message: Logged In: YES user_id=11105 And, BTW, building the bz2 extension on the compile farm solaris-x86 machine also fails with relocation errors (but I have no idea if that is related to the _ctypes build failure or not). ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-03 21:24 Message: Logged In: YES user_id=11105 What I've found out, after some painful time on the sourceforge compilefarm, is this: Python svn trunk also fails to build _ctypes.so on the solaris-x86 machine, but not on the sparc machines (both have solaris 9, I believe). ctypes from svn trunk *does* build also on the x86 machine, with the system installed python2.3, also with python 2.5b2. One difference that I found is that ctypes svn setup.py passes '-impure-text' to the linker, while python svn (when building the bundled ctypes) does not. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-02 15:20 Message: Logged In: YES user_id=11105 It seems that the files 'src/x86/ffi.c' and 'src/x86/sysv.S' are not needed for the X86_64 platform in fficonfig.py.in. They *should* compile to nothing, anyway, because their contents is protected by 'ifndef __x86_64__'. Does removing them from fficonfig.py.in change the situation, so that only this remains: 'X86_64': ['src/x86/ffi64.c', 'src/x86/unix64.S'], I can build _ctypes on an unbuntu amd64 system with this change. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-02 15:08 Message: Logged In: YES user_id=44345 I don't understand. I swapped the order of ffi.c and sysv.S in the platforms dict. I confirmed that the order of the .o files on the link line changed so that ffi.o followed sysv.o. I still get the same error. I've also confirmed that ffi.o exports the symbol and that sysv.o references it: % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000000 U _GLOBAL_OFFSET_TABLE_ 0000000000 f ffi.c 0000000332 T ffi_call 0000000000 U ffi_call_SYSV 0000000000 U ffi_closure_SYSV 0000000456 T ffi_closure_SYSV_inner 0000000000 T ffi_prep_args 0000000252 T ffi_prep_cif_machdep 0000000612 T ffi_prep_closure 0000000000 U memcpy % nm -p build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o: 0000000000 s 0000000000 s 0000000000 s 0000000000 s 0000000109 n epilogue 0000000000 T ffi_call_SYSV 0000000116 T ffi_closure_SYSV 0000000000 U ffi_closure_SYSV_inner 0000000000 U ffi_prep_args 0000000109 n noretval 0000000071 n retdouble 0000000059 n retfloat 0000000046 n retint 0000000095 n retint64 0000000083 n retlongdouble 0000000109 n retstruct All the object files were compiled with -fPIC. Here's the relevant chunk of make's output: creating build/temp.solaris-2.10-i86pc-2.5/libffi checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for gcc... /opt/app/g++lib6/gcc-3.4/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /opt/app/g++lib6/gcc-3.4/bin/gcc accepts -g... yes checking for /opt/app/g++lib6/gcc-3.4/bin/gcc option to accept ANSI C... none needed checking how to run the C preprocessor... /opt/app/g++lib6/gcc-3.4/bin/gcc -E checking for egrep... egrep checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking sys/mman.h usability... yes checking sys/mman.h presence... yes checking for sys/mman.h... yes checking for mmap... yes checking for sys/mman.h... (cached) yes checking for mmap... (cached) yes checking whether read-only mmap of a plain file works... yes checking whether mmap from /dev/zero works... yes checking for MAP_ANON(YMOUS)... yes checking whether mmap with MAP_ANON(YMOUS) works... yes checking for ANSI C header files... (cached) yes checking for memcpy... yes checking for working alloca.h... yes checking for alloca... yes checking for double... yes checking size of double... 8 checking for long double... yes checking size of long double... 12 checking whether byte ordering is bigendian... no checking whether .eh_frame section should be read-only... no checking for __attribute__((visibility("hidden")))... no configure: creating ./config.status config.status: creating include/ffi.h config.status: creating fficonfig.py config.status: creating fficonfig.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffitarget.h to include/ffitarget.h config.status: linking /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/include/ffi_common.h to include/ffi_common.h config.status: executing include commands config.status: executing src commands >>> X86_64 ['src/prep_cif.c', 'src/x86/ffi64.c', 'src/x86/unix64.S', 'src/x86/sysv.S', 'src/x86/ffi.c'] building '_ctypes' extension /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c: In function `_CallProc': /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.c:917: warning: implicit declaration of function `alloca' /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.S -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o /opt/app/g++lib6/gcc-3.4/bin/gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/home/ink/skipm/src/python-svn/trunk/./Include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi/include -Ibuild/temp.solaris-2.10-i86pc-2.5/libffi -I/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src -I/opt/app/nonc++/BerkleyDB-4.3/include -I/opt/app/nonc++/tcl-8.4/include -I/opt/app/nonc++/readline-4.3/include -I/opt/app/nonc++/gdbm-1.8/include -I../Include -I. -I/usr/local/include -I/home/ink/skipm/src/python-svn/trunk/Include -I/home/ink/skipm/src/python-svn/trunk/build -c /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c -o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:177: warning: function declaration isn't a prototype /home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.c:194: warning: function declaration isn't a prototype /opt/app/g++lib6/gcc-3.4/bin/gcc -shared build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o -L/usr/local/lib -o build/lib.solaris-2.10-i86pc-2.5/_ctypes.so Text relocation remains referenced against symbol offset in file ffi_closure_SYSV_inner 0x8e build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status I added a couple prints to fficonfig.py.in to demonstrate the file order and platform name (and to make sure fficonfig.py was being rebuilt). Oddly enough, if I remove both ffi.o and sysv.o from the link line, it links successfully. Is that significant or am I just getting desparate? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-08-01 22:02 Message: Logged In: YES user_id=11105 I didn't know there are any systems that depend on the order of object files on the linker command line any more ;-). IIUC, the objects list is derived by distutils from the sources list, so the attached patch (for Modules/_ctypes/libffi/fficonfig.py.in) *could* do the trick. Please make sure that fficonfig.py is recreated (by doing make clean before building or whatever). Thanks for looking into this. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-01 18:16 Message: Logged In: YES user_id=44345 Thomas> Skip, do you have *any* idea what might be Thomas> wrong, or could you even come up with a patch? Skip> I've no idea so far. I'll try to find some time Skip> to take a look at it later today. Thomas, Sorry for the delay. I think I have it figured out and it was fairly straightforward. Looking at the files in order on the _ctypes.so link line we see that the definition of ffi_closure_SYSV_inner is defined before it's referenced: for obj in build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o ; do echo $obj; nm -p $obj | egrep ffi_closure_SYSV_inner; done build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/_ctypes.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callbacks.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/callproc.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/cfield.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/malloc_closure.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/prep_cif.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/unix64.o build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/ffi.o 0000000456 T ffi_closure_SYSV_inner build/temp.solaris-2.10-i86pc-2.5/home/ink/skipm/src/python-svn/trunk/Modules/_ctypes/libffi/src/x86/sysv.o 0000000000 U ffi_closure_SYSV_inner Since we're linking from object files, it's a one-pass link algorithm. At the time ffo.o is examined, sysv.o hasn't been seen. Consequently, ffi_closure_SYSV_inner is not yet known and its definition isn't picked up from ffi.o. I couldn't quickly figure out where the link command is generated, but I'm sure you'll know where it resides. Either swap ffi.o and sysv.o on the link line, or add ffi.o a second time to resolve the new reference. Skip ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-31 12:54 Message: Logged In: YES user_id=11105 Skip, do you have *any* idea what might be wrong, or could you even come up with a patch? ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-07-29 00:03 Message: Logged In: YES user_id=44345 Yeah, you'd definitely need -fPIC on any brand of Solaris. That test might be changed to plat = get_platform() if plat in (... buncha platforms ...) or "solaris" in plat: os.environ["CFLAGS"] = "-fPIC" That doesn't seem to be what's happening in this case though. I rm'd the .o files in .../Modules/_ctypes and tried again. The compile commands *do* have -fPIC on them. I don't think it's required on the link line. S ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-28 18:19 Message: Logged In: YES user_id=11105 Skip, This looks *somewhat* like the problems reported in bugs 1529269 and 1528620 (although they have a sparc, and you seem to have x86 solaris). Hm, in the standalone ctypes setup script, I find this code snippet: if get_platform() in ["solaris-2.9-sun4u", "linux-x86_64"]: os.environ["CFLAGS"] = "-fPIC" Can it be that -fPIC must be used, but is not specified? It is also funny that the solaris buildbot does NOT seem to have a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530448&group_id=5470 From noreply at sourceforge.net Fri Aug 4 21:04:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 12:04:26 -0700 Subject: [ python-Bugs-1529269 ] Python 2.5b2 fails to build on Solaris 10 (GCC Compiler) Message-ID: Bugs item #1529269, was opened at 2006-07-26 23:17 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529269&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Guido Ostkamp (ostkamp) Assigned to: Thomas Heller (theller) Summary: Python 2.5b2 fails to build on Solaris 10 (GCC Compiler) Initial Comment: Hello, as promised here is the second report because of problems with building Python 2.5b2 on Solaris 10 (Sparc). I have been using the GCC this time. These are the problems (for full logs please see attachments): building '_ctypes' extension gcc -shared build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules /_ctypes/_ctypes.o build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/ Modules/_ctypes/callbacks.o build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Pyth on-2.5b2/Modules/_ctypes/callproc.o build/temp.solaris-2.10-sun4us-2.5/home/ostk amp/Python-2.5b2/Modules/_ctypes/stgdict.o build/temp.solaris-2.10-sun4us-2.5/ho me/ostkamp/Python-2.5b2/Modules/_ctypes/cfield.o build/temp.solaris-2.10-sun4us- 2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/malloc_closure.o build/temp.solari s-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/prep_cif. o build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules/_ctypes/l ibffi/src/sparc/ffi.o build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5 b2/Modules/_ctypes/libffi/src/sparc/v8.o build/temp.solaris-2.10-sun4us-2.5/home /ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v9.o -o build/lib.solaris -2.10-sun4us-2.5/_ctypes.so ld: fatal: relocation error: R_SPARC_32: file build/temp.solaris-2.10-sun4us-2.5 /home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o: symbol : offset 0xfeedcca5 is non-aligned ld: fatal: relocation error: R_SPARC_32: file build/temp.solaris-2.10-sun4us-2.5 /home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o: symbol : offset 0xfeedccab is non-aligned ld: fatal: relocation error: R_SPARC_32: file build/temp.solaris-2.10-sun4us-2.5 /home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o: symbol : offset 0xfeedccaf is non-aligned ld: fatal: relocation error: R_SPARC_32: file build/temp.solaris-2.10-sun4us-2.5 /home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o: symbol : offset 0xfeedccb3 is non-aligned ld: fatal: relocation error: R_SPARC_32: file build/temp.solaris-2.10-sun4us-2.5 /home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o: symbol : offset 0xfeeeae06 is non-aligned ld: fatal: relocation error: R_SPARC_32: file build/temp.solaris-2.10-sun4us-2.5 /home/ostkamp/Python-2.5b2/Modules/_ctypes/libffi/src/sparc/v8.o: symbol : offset 0xfeeecaf6 is non-aligned collect2: ld returned 1 exit status building '_curses' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/ home/ostkamp/Python-2.5b2/./Include -I./Include -I. -I/home/ostkamp/Python-2.5b2 /Include -I/home/ostkamp/Python-2.5b2 -c /home/ostkamp/Python-2.5b2/Modules/_cur sesmodule.c -o build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu les/_cursesmodule.o /home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c: In function `PyCursesWindow_ GetStr': /home/ostkamp/Python-2.5b2/Modules/_cursesmodule.c:822: warning: implicit declar ation of function `mvwgetnstr' gcc -shared build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules /_cursesmodule.o -lcurses -ltermcap -o build/lib.solaris-2.10-sun4us-2.5/_curses .so *** WARNING: renaming "_curses" since importing it failed: ld.so.1: python: fata l: relocation error: file build/lib.solaris-2.10-sun4us-2.5/_curses.so: symbol m vwgetnstr: referenced symbol not found building '_curses_panel' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I/ home/ostkamp/Python-2.5b2/./Include -I./Include -I. -I/home/ostkamp/Python-2.5b2 /Include -I/home/ostkamp/Python-2.5b2 -c /home/ostkamp/Python-2.5b2/Modules/_cur ses_panel.c -o build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modu les/_curses_panel.o gcc -shared build/temp.solaris-2.10-sun4us-2.5/home/ostkamp/Python-2.5b2/Modules /_curses_panel.o -lpanel -lcurses -ltermcap -o build/lib.solaris-2.10-sun4us-2.5 /_curses_panel.so *** WARNING: renaming "_curses_panel" since importing it failed: No module named _curses running build_scripts Regards, Guido ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-08-04 21:04 Message: Logged In: YES user_id=11105 Guido, in SVN revision 51113 a change was committed that adds the '-mimpure-text' flag to the linker when linking the _ctypes.so file. This fixed the build on solaris x86 (there were relocation errors before). Can you try if that helps in your case? Thanks. See also http://python.org/sf/1530448 . ---------------------------------------------------------------------- Comment By: Guido Ostkamp (ostkamp) Date: 2006-07-28 13:28 Message: Logged In: YES user_id=1028306 @theller: I have tried --with-pydebug, but it gives the same errors. Please find logfile attached. @nnorwitz: I remove the Python-2.5b2 directory and execute a fresh untar, configure etc. for each try. So there is no interference with results from different compilers. In case it matters, I checked for the GCC version used. I think it came with the Solaris distribution and does use the system-ld, not gnu-ld (see below for config output): $ gcc -v Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs Configured with: /gates/sfw10/builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) This is from package $ pkginfo -l SUNWgcc PKGINST: SUNWgcc NAME: gcc - The GNU C compiler CATEGORY: system ARCH: sparc VERSION: 11.10.0,REV=2005.01.08.05.16 BASEDIR: / VENDOR: Sun Microsystems, Inc. DESC: GNU C - The GNU C compiler 3.4.3 PSTAMP: sfw1020050108051924 INSTDATE: Mar 20 2006 14:30 HOTLINE: Please contact your local service provider STATUS: completely installed FILES: 296 installed pathnames 6 shared pathnames 5 linked files 25 directories 33 executables 104325 blocks used (approx) Regards, Guido ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-28 06:53 Message: Logged In: YES user_id=33168 Hmmm, I thought this was the report from using sun studio compiler. Guido, are you sure you did a make clean in between using different compilers? ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-07-27 19:23 Message: Logged In: YES user_id=11105 I don't have access to a solaris 10 box myself (only the sourceforge solaris 9 sparc machine). I'm wondering why the solaris 10 machine running the Python buildbot does not report any problems, could it be that this is because it run configure with '--with-pydebug' ? Guido, can you please try this? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-27 05:21 Message: Logged In: YES user_id=33168 Thomas can you check out the ctypes problems? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529269&group_id=5470 From noreply at sourceforge.net Fri Aug 4 21:11:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 12:11:53 -0700 Subject: [ python-Bugs-1534738 ] Win32 debug version of _msi creates _msi.pyd, not _msi_d.pyd Message-ID: Bugs item #1534738, was opened at 2006-08-04 19:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534738&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: Win32 debug version of _msi creates _msi.pyd, not _msi_d.pyd Initial Comment: The .vcproj file has the the output file set to _msi.pyd for the debug target instead of _msi_d.pyd so the incorrect file is created. This leads to a crash if python.exe tries to import _msi and _msi.pyd is the debug version. The fix is to add a _d to the output file field for the debug target. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534738&group_id=5470 From noreply at sourceforge.net Fri Aug 4 21:54:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 12:54:35 -0700 Subject: [ python-Bugs-1534738 ] Win32 debug version of _msi creates _msi.pyd, not _msi_d.pyd Message-ID: Bugs item #1534738, was opened at 2006-08-04 21:11 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534738&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: Win32 debug version of _msi creates _msi.pyd, not _msi_d.pyd Initial Comment: The .vcproj file has the the output file set to _msi.pyd for the debug target instead of _msi_d.pyd so the incorrect file is created. This leads to a crash if python.exe tries to import _msi and _msi.pyd is the debug version. The fix is to add a _d to the output file field for the debug target. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-08-04 21:54 Message: Logged In: YES user_id=11105 I made the change to the PCBuild/_msi.vcproj file in SVN r51114, someone with Visual Studio 2005 should probably fix PCBuild8/_msi.vcproj as well and close this bug. Thanks for the heads up, John. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534738&group_id=5470 From noreply at sourceforge.net Fri Aug 4 21:57:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 12:57:36 -0700 Subject: [ python-Bugs-1534764 ] sys.path gets munged with certain directory structures Message-ID: Bugs item #1534764, was opened at 2006-08-04 14:57 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534764&group_id=5470 Please note that this 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: Gustavo Tabares (gustavotabares) Assigned to: Nobody/Anonymous (nobody) Summary: sys.path gets munged with certain directory structures Initial Comment: Platform: Windows XP SP2 Python Version: 2.4.2 final First off, I'm not sure if this is the same bug as 947380 . Comments say it was fixed in Python 2.4, but I'm running Python 2.4.2 and it looks like I'm hitting the same issue. If this is the same issue and has been fixed in a later version, I apologize. To reproduce: 1. Create a new directory (e.g., 'foo'). 2. Inside foo, create a __init__.py along with a directory called 'stat' which also has an empty __init__.py inside of it. 3. 'cd' to this directory via the command line and start the Python interpreter. Observe the 'import site' failed error. A quick check at sys.path reveals that sys.path is munged and doesn't contain all that it should. WORKAROUND: Rename 'stat' directory to 'stats' or something else. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534764&group_id=5470 From noreply at sourceforge.net Fri Aug 4 21:58:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 12:58:04 -0700 Subject: [ python-Bugs-1534765 ] logging's fileConfig causes KeyError on shutdown Message-ID: Bugs item #1534765, was opened at 2006-08-04 15:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534765&group_id=5470 Please note that this 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: mdbeachy (mdbeachy) Assigned to: Nobody/Anonymous (nobody) Summary: logging's fileConfig causes KeyError on shutdown Initial Comment: If logging.config.fileConfig() is called after logging handlers already exist, a KeyError is thrown in the atexit call to logging.shutdown(). This looks like it's fixed in the 2.5 branch but since I've bothered to figure out what was going on I'm sending this in anyway. There still might be a 2.4.4, right? (Also, my fix looks better than what was done for 2.5, but I suppose the flush/close I added may not be necessary.) Attached is a demo and a patch against 2.4.3. Thanks, Mike ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534765&group_id=5470 From noreply at sourceforge.net Fri Aug 4 22:04:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 13:04:15 -0700 Subject: [ python-Bugs-1433886 ] pointer aliasing causes core dump, with workaround Message-ID: Bugs item #1433886, was opened at 2006-02-17 16:56 Message generated for change (Comment added) made by qbarnes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&group_id=5470 Please note that this 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: Quentin Barnes (qbarnes) Assigned to: Nobody/Anonymous (nobody) Summary: pointer aliasing causes core dump, with workaround Initial Comment: When building 2.3.3 on Solaris using Studio 11 and "-xalias_level=std" to enable ISO C99 pointer aliasing rules, the interpreter would core dump when running test_descr2.py. From examining the source, I believe this problem exists in 2.4.2 as well, but did not verify it. I was able to simplify the code to invoke the problem down to: ==== class C1(object): def __new__(cls): return super(C1, cls).__new__(cls) a = C1() ==== I tracked the problem to super_init() in Objects/typeobject.c. The local variable "obj" is of type "PyObject *" and "type" is of type "PyTypeObject *". In this function, both variables can be pointing to the same object in memory. Since the pointers are not of compatible types, the compiler ends up optimizing out a memory load between Py_INCREF(obj) and Py_INCREF(type) caching a previously read value. This causes the object reference counter to only be incremented once instead of twice. When the object is deallocated, the interpreter blows up. A workaround is to cast one of the pointers to the others type so that the compiler can see the pointer aliasing potential. This is what I did in the patch. What I suspect needs to be done as a more global fix is to discontinue use of the PyObject_VAR_HEAD macro hack. Casting between structures containing this macro creates ISO C99 pointer aliasing violations. The contents of the macro needs to be in its own structure which is referenced so a compliant compiler can know of possible aliasing. ---------------------------------------------------------------------- >Comment By: Quentin Barnes (qbarnes) Date: 2006-08-04 15:04 Message: Logged In: YES user_id=288734 It doesn't matter which standard is used, C99 or C89, the aliasing violation is the same. An object is being accessed through two different aggregate type aliases. The language in C99 section 6.5 is the same in this regards as C89 section 3.3. (Actually, C99 is slightly looser than C89 since it allows effective type aliasing which C89 does not have.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-08-03 21:47 Message: Logged In: YES user_id=31435 Yes, Python must be compiled with -fno-strict-aliasing (or moral equivalent). No, that's not going to change before Python 3000 (if even then). All Python object structs conceptually extend the PyObject struct, including (but not limited to) object structs conceptually extending the PyVarObject struct (which in turn conceptually extends the PyObject struct). This is uniquitous in the core source code, and in all 3rd-party extension modules defining new Python objects in C. Note that Python doesn't much care about C99. It was written against K&R C, and went nearly a decade before requiring C89 (it took that long for C89-conforming compilers to show up on all interesting Python platforms). Best guess is that it will never require C99 (because best guess is that C99-conforming compilers will never show up on all interesting Python platforms). That said, I don't see anything to object to in adding fiddly casting patches to make sure compilers don't try to exploit the trivial optimization opportunities that assuming no aliasing in the Python source may allow. ---------------------------------------------------------------------- Comment By: Quentin Barnes (qbarnes) Date: 2006-08-03 21:24 Message: Logged In: YES user_id=288734 There is no reason why the source code for Python cannot conform to ISO C99 pointer aliasing rules. If pointers are being improperly aliased violating the C standard, it's just bad programming practice. The only reason to use a switch like GCC's -fno-strict-aliasing or Solaris' -xalias_level=any is for old legacy code, not well-programmed, actively maintained code. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 16:24 Message: Logged In: YES user_id=11375 I have the vague impression that Python's code doesn't conform to strict aliasing, and it therefore must always be compiled with GCC's -fno-strict-aliasing option or the equivalent. Your fix might avoid that one problem, but there might be other subtle bugs. Assigning to Tim Peters, who will know if the -fno-strict-aliasing statement is correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&group_id=5470 From noreply at sourceforge.net Fri Aug 4 22:07:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 13:07:01 -0700 Subject: [ python-Bugs-1534769 ] Identical floats print inconsistently Message-ID: Bugs item #1534769, was opened at 2006-08-04 20: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=1534769&group_id=5470 Please note that this 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: Marc W. Abel (gihon) Assigned to: Nobody/Anonymous (nobody) Summary: Identical floats print inconsistently Initial Comment: Hi, and thank you. Many bugs relating to this have been submitted by others over a period of years, and these have generally been closed with "not a bug" responses. I'll do my best to explain the problem clearly enough. The following session prints a single variable three ways, with two different results: ----------- [me at localhost current]$ python Python 2.4.1 (#1, May 16 2005, 15:19:29) [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a = round(1./7, 3) >>> print a 0.143 >>> print (a,) (0.14299999999999999,) >>> print (a,)[0] 0.143 >>> ----------- I'm fully informed about IEEE floating point representations in binary, but the limitations of data type are not causing the difference in output. The interpreter is using different rules to print this float, depending on whether it's a straight float or part of some other structure (in this example, a tuple). Once the interpreter recurses to a depth where it's clearly going to print a float, whatever rule is selected needs to be consistently applied. This means calling the same string formatting code with the same inputs. Marc ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534769&group_id=5470 From noreply at sourceforge.net Fri Aug 4 22:14:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 13:14:06 -0700 Subject: [ python-Bugs-1534769 ] Identical floats print inconsistently Message-ID: Bugs item #1534769, was opened at 2006-08-04 20:07 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534769&group_id=5470 Please note that this 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: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Marc W. Abel (gihon) Assigned to: Nobody/Anonymous (nobody) Summary: Identical floats print inconsistently Initial Comment: Hi, and thank you. Many bugs relating to this have been submitted by others over a period of years, and these have generally been closed with "not a bug" responses. I'll do my best to explain the problem clearly enough. The following session prints a single variable three ways, with two different results: ----------- [me at localhost current]$ python Python 2.4.1 (#1, May 16 2005, 15:19:29) [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a = round(1./7, 3) >>> print a 0.143 >>> print (a,) (0.14299999999999999,) >>> print (a,)[0] 0.143 >>> ----------- I'm fully informed about IEEE floating point representations in binary, but the limitations of data type are not causing the difference in output. The interpreter is using different rules to print this float, depending on whether it's a straight float or part of some other structure (in this example, a tuple). Once the interpreter recurses to a depth where it's clearly going to print a float, whatever rule is selected needs to be consistently applied. This means calling the same string formatting code with the same inputs. Marc ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-04 20:14 Message: Logged In: YES user_id=849994 Sorry, but this is another "not a bug". "print tuple" invokes tuple.__repr__() (because there is no separate __str__) which invokes repr(item) on each tuple item, while "print item" invokes str(item). For floats, this distinction results in a different rounding precision. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534769&group_id=5470 From noreply at sourceforge.net Fri Aug 4 22:14:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 13:14:41 -0700 Subject: [ python-Bugs-1534765 ] logging's fileConfig causes KeyError on shutdown Message-ID: Bugs item #1534765, was opened at 2006-08-04 19:58 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534765&group_id=5470 Please note that this 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: mdbeachy (mdbeachy) >Assigned to: Vinay Sajip (vsajip) Summary: logging's fileConfig causes KeyError on shutdown Initial Comment: If logging.config.fileConfig() is called after logging handlers already exist, a KeyError is thrown in the atexit call to logging.shutdown(). This looks like it's fixed in the 2.5 branch but since I've bothered to figure out what was going on I'm sending this in anyway. There still might be a 2.4.4, right? (Also, my fix looks better than what was done for 2.5, but I suppose the flush/close I added may not be necessary.) Attached is a demo and a patch against 2.4.3. Thanks, Mike ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534765&group_id=5470 From noreply at sourceforge.net Fri Aug 4 22:22:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 13:22:15 -0700 Subject: [ python-Bugs-1522046 ] RPM build fails for Py2.5b2 Message-ID: Bugs item #1522046, was opened at 2006-07-13 13:55 Message generated for change (Comment added) made by breadman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522046&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Behnel (scoder) Assigned to: Nobody/Anonymous (nobody) Summary: RPM build fails for Py2.5b2 Initial Comment: Using Misc/RPM/python-2.5.spec, Python 2.5b2 fails to compile into an RPM on my machine (SuSE 10.1, AMD64, gcc 4.1). Unlike with b1, I get loads of errors saying: "ld: cannot find -lpython2.5" The funny thing is that it continues to build and only fails at the end when collecting the files for the RPM. I use configure --enable-shared --enable-unicode=ucs4 \ --enable-ipv6 --with-pymalloc --prefix=/usr \ --libdir=/usr/lib64 The shared library is correctly built before these errors come up. The error appear on the "sharedmods" target. I also tried setting LD_LIBRARY_PATH by hand, although the build script sets it before starting to build the modules - no help. What *does* help is adding "-L." to the LDFLAGS in Makefile.pre.in: sed -e '/DIR=.*lib$/ s|/lib$|/%{libdirname}| ; \ /LDFLAGS/ s|LDFLAGS=|LDFLAGS= -L. |' \ ./Makefile.pre.in.old >Makefile.pre.in The "DIR=" is for an x86_64 bug that installs Python to the wrong directory (/usr/lib instead of /usr/lib64). I tried building Py2.5 by hand (configure/make) and that also works nicely. I attached a patch that fixes the problems I encountered. ---------------------------------------------------------------------- Comment By: Eric Wald (breadman) Date: 2006-08-04 14:22 Message: Logged In: YES user_id=324500 Seems to be fixed in 2.5b3. ---------------------------------------------------------------------- Comment By: Eric Wald (breadman) Date: 2006-08-03 14:12 Message: Logged In: YES user_id=324500 There is a deeper issue here: Dynamic extensions fail to link until after libpython2.5.so.1.0 is installed. The '-L.' flag is the better approach to fixing this bug, but perhaps it should use the full path name, like the LD_LIBRARY_PATH environment variable used when running setup.py. Unfortunately, this bug is hidden from people compiling on top of an earlier 2.5 installation, where the link step will find and use the old library; for others, it is resolved in installation, where make will happily link the extensions if they failed to link earlier, right after installing the library. However, it means that the dynamic libraries are unavailable between the build and install steps. One major result is that the test suite refuses to run at that time. It also means that 'make install' can cause the linker to be called, which is generally discouraged. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522046&group_id=5470 From noreply at sourceforge.net Fri Aug 4 23:10:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 14:10:25 -0700 Subject: [ python-Bugs-1433886 ] pointer aliasing causes core dump, with workaround Message-ID: Bugs item #1433886, was opened at 2006-02-17 17:56 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&group_id=5470 Please note that this 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: Quentin Barnes (qbarnes) Assigned to: Nobody/Anonymous (nobody) Summary: pointer aliasing causes core dump, with workaround Initial Comment: When building 2.3.3 on Solaris using Studio 11 and "-xalias_level=std" to enable ISO C99 pointer aliasing rules, the interpreter would core dump when running test_descr2.py. From examining the source, I believe this problem exists in 2.4.2 as well, but did not verify it. I was able to simplify the code to invoke the problem down to: ==== class C1(object): def __new__(cls): return super(C1, cls).__new__(cls) a = C1() ==== I tracked the problem to super_init() in Objects/typeobject.c. The local variable "obj" is of type "PyObject *" and "type" is of type "PyTypeObject *". In this function, both variables can be pointing to the same object in memory. Since the pointers are not of compatible types, the compiler ends up optimizing out a memory load between Py_INCREF(obj) and Py_INCREF(type) caching a previously read value. This causes the object reference counter to only be incremented once instead of twice. When the object is deallocated, the interpreter blows up. A workaround is to cast one of the pointers to the others type so that the compiler can see the pointer aliasing potential. This is what I did in the patch. What I suspect needs to be done as a more global fix is to discontinue use of the PyObject_VAR_HEAD macro hack. Casting between structures containing this macro creates ISO C99 pointer aliasing violations. The contents of the macro needs to be in its own structure which is referenced so a compliant compiler can know of possible aliasing. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-08-04 17:10 Message: Logged In: YES user_id=31435 Sorry, but it still doesn't really matter what any version of the C standard says here: the /conceptual/ extension of the PyObject struct by all Python object structs is the source of the problem, and is ubiquitous both within the core and throughout countless 3rd-party extension modules. This isn't realistically fixable before Python 3000. In the meantime, use of the platform equivalent to gcc's -fno-strict-aliasing option is necessary. ---------------------------------------------------------------------- Comment By: Quentin Barnes (qbarnes) Date: 2006-08-04 16:04 Message: Logged In: YES user_id=288734 It doesn't matter which standard is used, C99 or C89, the aliasing violation is the same. An object is being accessed through two different aggregate type aliases. The language in C99 section 6.5 is the same in this regards as C89 section 3.3. (Actually, C99 is slightly looser than C89 since it allows effective type aliasing which C89 does not have.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-08-03 22:47 Message: Logged In: YES user_id=31435 Yes, Python must be compiled with -fno-strict-aliasing (or moral equivalent). No, that's not going to change before Python 3000 (if even then). All Python object structs conceptually extend the PyObject struct, including (but not limited to) object structs conceptually extending the PyVarObject struct (which in turn conceptually extends the PyObject struct). This is uniquitous in the core source code, and in all 3rd-party extension modules defining new Python objects in C. Note that Python doesn't much care about C99. It was written against K&R C, and went nearly a decade before requiring C89 (it took that long for C89-conforming compilers to show up on all interesting Python platforms). Best guess is that it will never require C99 (because best guess is that C99-conforming compilers will never show up on all interesting Python platforms). That said, I don't see anything to object to in adding fiddly casting patches to make sure compilers don't try to exploit the trivial optimization opportunities that assuming no aliasing in the Python source may allow. ---------------------------------------------------------------------- Comment By: Quentin Barnes (qbarnes) Date: 2006-08-03 22:24 Message: Logged In: YES user_id=288734 There is no reason why the source code for Python cannot conform to ISO C99 pointer aliasing rules. If pointers are being improperly aliased violating the C standard, it's just bad programming practice. The only reason to use a switch like GCC's -fno-strict-aliasing or Solaris' -xalias_level=any is for old legacy code, not well-programmed, actively maintained code. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 17:24 Message: Logged In: YES user_id=11375 I have the vague impression that Python's code doesn't conform to strict aliasing, and it therefore must always be compiled with GCC's -fno-strict-aliasing option or the equivalent. Your fix might avoid that one problem, but there might be other subtle bugs. Assigning to Tim Peters, who will know if the -fno-strict-aliasing statement is correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&group_id=5470 From noreply at sourceforge.net Fri Aug 4 23:24:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 14:24:13 -0700 Subject: [ python-Bugs-1534769 ] Identical floats print inconsistently Message-ID: Bugs item #1534769, was opened at 2006-08-04 16: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=1534769&group_id=5470 Please note that this 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: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Marc W. Abel (gihon) Assigned to: Nobody/Anonymous (nobody) Summary: Identical floats print inconsistently Initial Comment: Hi, and thank you. Many bugs relating to this have been submitted by others over a period of years, and these have generally been closed with "not a bug" responses. I'll do my best to explain the problem clearly enough. The following session prints a single variable three ways, with two different results: ----------- [me at localhost current]$ python Python 2.4.1 (#1, May 16 2005, 15:19:29) [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a = round(1./7, 3) >>> print a 0.143 >>> print (a,) (0.14299999999999999,) >>> print (a,)[0] 0.143 >>> ----------- I'm fully informed about IEEE floating point representations in binary, but the limitations of data type are not causing the difference in output. The interpreter is using different rules to print this float, depending on whether it's a straight float or part of some other structure (in this example, a tuple). Once the interpreter recurses to a depth where it's clearly going to print a float, whatever rule is selected needs to be consistently applied. This means calling the same string formatting code with the same inputs. Marc ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-08-04 17:24 Message: Logged In: YES user_id=31435 gbrandl is correct that the differences here are entirely due to the difference between float's __repr__ and __str__ methods. The reasons they /are/ different for floats are explained in the Tutorial's appendix on floating-point issues. It may be considered unfortunate that tuple.__repr__ is the same as tuple.__str__, and that both "pass repr down" to containees, but the reason for that has to do with the difference between str.__repr__ and str.__str__. If str(tuple) "passed str down" to containees, then, e.g., print ("a, bc", "de f,", "gh), i") would display the incomprehensibly confused: (a, bc, de f,, gh), i) IOW, it's actually the difference in what string types do that /drives/ the general decision that c.__str__ is the same as c.__repr__ for all objects `c` of container types, and that both "pass repr down" to containees. Alas, that's not always what people using strings want either :-) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-04 16:14 Message: Logged In: YES user_id=849994 Sorry, but this is another "not a bug". "print tuple" invokes tuple.__repr__() (because there is no separate __str__) which invokes repr(item) on each tuple item, while "print item" invokes str(item). For floats, this distinction results in a different rounding precision. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534769&group_id=5470 From noreply at sourceforge.net Fri Aug 4 23:30:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 14:30:24 -0700 Subject: [ python-Bugs-1433886 ] pointer aliasing causes core dump, with workaround Message-ID: Bugs item #1433886, was opened at 2006-02-17 16:56 Message generated for change (Comment added) made by qbarnes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&group_id=5470 Please note that this 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: Quentin Barnes (qbarnes) Assigned to: Nobody/Anonymous (nobody) Summary: pointer aliasing causes core dump, with workaround Initial Comment: When building 2.3.3 on Solaris using Studio 11 and "-xalias_level=std" to enable ISO C99 pointer aliasing rules, the interpreter would core dump when running test_descr2.py. From examining the source, I believe this problem exists in 2.4.2 as well, but did not verify it. I was able to simplify the code to invoke the problem down to: ==== class C1(object): def __new__(cls): return super(C1, cls).__new__(cls) a = C1() ==== I tracked the problem to super_init() in Objects/typeobject.c. The local variable "obj" is of type "PyObject *" and "type" is of type "PyTypeObject *". In this function, both variables can be pointing to the same object in memory. Since the pointers are not of compatible types, the compiler ends up optimizing out a memory load between Py_INCREF(obj) and Py_INCREF(type) caching a previously read value. This causes the object reference counter to only be incremented once instead of twice. When the object is deallocated, the interpreter blows up. A workaround is to cast one of the pointers to the others type so that the compiler can see the pointer aliasing potential. This is what I did in the patch. What I suspect needs to be done as a more global fix is to discontinue use of the PyObject_VAR_HEAD macro hack. Casting between structures containing this macro creates ISO C99 pointer aliasing violations. The contents of the macro needs to be in its own structure which is referenced so a compliant compiler can know of possible aliasing. ---------------------------------------------------------------------- >Comment By: Quentin Barnes (qbarnes) Date: 2006-08-04 16:30 Message: Logged In: YES user_id=288734 I wasn't demanding the bug be fixed in the present source base. I understand that's impractical due to the invasive nature of the PyObject_VAR_HEAD macro trick. I was just trying to clarify that the trick is an invalid coding practice even under C89. I didn't want people assuming it was ok because of them thinking it was only a problem under C99 and later standards while safe under C89. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-08-04 16:10 Message: Logged In: YES user_id=31435 Sorry, but it still doesn't really matter what any version of the C standard says here: the /conceptual/ extension of the PyObject struct by all Python object structs is the source of the problem, and is ubiquitous both within the core and throughout countless 3rd-party extension modules. This isn't realistically fixable before Python 3000. In the meantime, use of the platform equivalent to gcc's -fno-strict-aliasing option is necessary. ---------------------------------------------------------------------- Comment By: Quentin Barnes (qbarnes) Date: 2006-08-04 15:04 Message: Logged In: YES user_id=288734 It doesn't matter which standard is used, C99 or C89, the aliasing violation is the same. An object is being accessed through two different aggregate type aliases. The language in C99 section 6.5 is the same in this regards as C89 section 3.3. (Actually, C99 is slightly looser than C89 since it allows effective type aliasing which C89 does not have.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-08-03 21:47 Message: Logged In: YES user_id=31435 Yes, Python must be compiled with -fno-strict-aliasing (or moral equivalent). No, that's not going to change before Python 3000 (if even then). All Python object structs conceptually extend the PyObject struct, including (but not limited to) object structs conceptually extending the PyVarObject struct (which in turn conceptually extends the PyObject struct). This is uniquitous in the core source code, and in all 3rd-party extension modules defining new Python objects in C. Note that Python doesn't much care about C99. It was written against K&R C, and went nearly a decade before requiring C89 (it took that long for C89-conforming compilers to show up on all interesting Python platforms). Best guess is that it will never require C99 (because best guess is that C99-conforming compilers will never show up on all interesting Python platforms). That said, I don't see anything to object to in adding fiddly casting patches to make sure compilers don't try to exploit the trivial optimization opportunities that assuming no aliasing in the Python source may allow. ---------------------------------------------------------------------- Comment By: Quentin Barnes (qbarnes) Date: 2006-08-03 21:24 Message: Logged In: YES user_id=288734 There is no reason why the source code for Python cannot conform to ISO C99 pointer aliasing rules. If pointers are being improperly aliased violating the C standard, it's just bad programming practice. The only reason to use a switch like GCC's -fno-strict-aliasing or Solaris' -xalias_level=any is for old legacy code, not well-programmed, actively maintained code. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 16:24 Message: Logged In: YES user_id=11375 I have the vague impression that Python's code doesn't conform to strict aliasing, and it therefore must always be compiled with GCC's -fno-strict-aliasing option or the equivalent. Your fix might avoid that one problem, but there might be other subtle bugs. Assigning to Tim Peters, who will know if the -fno-strict-aliasing statement is correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&group_id=5470 From noreply at sourceforge.net Fri Aug 4 23:41:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 14:41:53 -0700 Subject: [ python-Bugs-1433886 ] pointer aliasing causes core dump, with workaround Message-ID: Bugs item #1433886, was opened at 2006-02-17 17:56 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&group_id=5470 Please note that this 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: Quentin Barnes (qbarnes) Assigned to: Nobody/Anonymous (nobody) Summary: pointer aliasing causes core dump, with workaround Initial Comment: When building 2.3.3 on Solaris using Studio 11 and "-xalias_level=std" to enable ISO C99 pointer aliasing rules, the interpreter would core dump when running test_descr2.py. From examining the source, I believe this problem exists in 2.4.2 as well, but did not verify it. I was able to simplify the code to invoke the problem down to: ==== class C1(object): def __new__(cls): return super(C1, cls).__new__(cls) a = C1() ==== I tracked the problem to super_init() in Objects/typeobject.c. The local variable "obj" is of type "PyObject *" and "type" is of type "PyTypeObject *". In this function, both variables can be pointing to the same object in memory. Since the pointers are not of compatible types, the compiler ends up optimizing out a memory load between Py_INCREF(obj) and Py_INCREF(type) caching a previously read value. This causes the object reference counter to only be incremented once instead of twice. When the object is deallocated, the interpreter blows up. A workaround is to cast one of the pointers to the others type so that the compiler can see the pointer aliasing potential. This is what I did in the patch. What I suspect needs to be done as a more global fix is to discontinue use of the PyObject_VAR_HEAD macro hack. Casting between structures containing this macro creates ISO C99 pointer aliasing violations. The contents of the macro needs to be in its own structure which is referenced so a compliant compiler can know of possible aliasing. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-08-04 17:41 Message: Logged In: YES user_id=31435 Ah, OK, and I have no argument with that. Well ;-), I'd state it more strongly: there are > 150 places in the core that stick PyObject_HEAD at the start of a struct declaration, and so, e.g., there are potential aliasing problems even between PyObject* and PyIntObject* pointers. IOW, PyObject_VAR_HEAD isn't the whole story here (or even most of it). ---------------------------------------------------------------------- Comment By: Quentin Barnes (qbarnes) Date: 2006-08-04 17:30 Message: Logged In: YES user_id=288734 I wasn't demanding the bug be fixed in the present source base. I understand that's impractical due to the invasive nature of the PyObject_VAR_HEAD macro trick. I was just trying to clarify that the trick is an invalid coding practice even under C89. I didn't want people assuming it was ok because of them thinking it was only a problem under C99 and later standards while safe under C89. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-08-04 17:10 Message: Logged In: YES user_id=31435 Sorry, but it still doesn't really matter what any version of the C standard says here: the /conceptual/ extension of the PyObject struct by all Python object structs is the source of the problem, and is ubiquitous both within the core and throughout countless 3rd-party extension modules. This isn't realistically fixable before Python 3000. In the meantime, use of the platform equivalent to gcc's -fno-strict-aliasing option is necessary. ---------------------------------------------------------------------- Comment By: Quentin Barnes (qbarnes) Date: 2006-08-04 16:04 Message: Logged In: YES user_id=288734 It doesn't matter which standard is used, C99 or C89, the aliasing violation is the same. An object is being accessed through two different aggregate type aliases. The language in C99 section 6.5 is the same in this regards as C89 section 3.3. (Actually, C99 is slightly looser than C89 since it allows effective type aliasing which C89 does not have.) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-08-03 22:47 Message: Logged In: YES user_id=31435 Yes, Python must be compiled with -fno-strict-aliasing (or moral equivalent). No, that's not going to change before Python 3000 (if even then). All Python object structs conceptually extend the PyObject struct, including (but not limited to) object structs conceptually extending the PyVarObject struct (which in turn conceptually extends the PyObject struct). This is uniquitous in the core source code, and in all 3rd-party extension modules defining new Python objects in C. Note that Python doesn't much care about C99. It was written against K&R C, and went nearly a decade before requiring C89 (it took that long for C89-conforming compilers to show up on all interesting Python platforms). Best guess is that it will never require C99 (because best guess is that C99-conforming compilers will never show up on all interesting Python platforms). That said, I don't see anything to object to in adding fiddly casting patches to make sure compilers don't try to exploit the trivial optimization opportunities that assuming no aliasing in the Python source may allow. ---------------------------------------------------------------------- Comment By: Quentin Barnes (qbarnes) Date: 2006-08-03 22:24 Message: Logged In: YES user_id=288734 There is no reason why the source code for Python cannot conform to ISO C99 pointer aliasing rules. If pointers are being improperly aliased violating the C standard, it's just bad programming practice. The only reason to use a switch like GCC's -fno-strict-aliasing or Solaris' -xalias_level=any is for old legacy code, not well-programmed, actively maintained code. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 17:24 Message: Logged In: YES user_id=11375 I have the vague impression that Python's code doesn't conform to strict aliasing, and it therefore must always be compiled with GCC's -fno-strict-aliasing option or the equivalent. Your fix might avoid that one problem, but there might be other subtle bugs. Assigning to Tim Peters, who will know if the -fno-strict-aliasing statement is correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1433886&group_id=5470 From noreply at sourceforge.net Sat Aug 5 04:20:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 4 Aug 2006 19:20:33 -0700 Subject: [ python-Feature Requests-1474577 ] feature requests for logging lib Message-ID: <200608050220.k752KXks017526@sc8-sf-db2-new-b.sourceforge.net> Feature Requests item #1474577, was opened at 2006-04-22 02:50 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474577&group_id=5470 Please note that this 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: Invalid Priority: 5 Submitted By: blaize rhodes (blaize) Assigned to: Vinay Sajip (vsajip) Summary: feature requests for logging lib Initial Comment: The logger module interface is a bit broken, I reckon. My problems specifically are: i) It's hard to get access to the LogRecord classes for customization. ii) the semantics of the debug, log, info, etc calls is a bit strange/confusing... Here are my proposed fixes: a) Add a method Logger.setLogRecordClass( myLogRecordSubClass ) which sets the class that is instantiated in the makeRecord() fn/method (yes there are two of them). This would make customizing the LogRecord easier... Otherwise (I believe) in order to subclass the LogRecord you also have to overload the Logger and possibly the root makeRecord() function as well? This bloke's writen up his approach to this (it's doable but not as nice as it should be). http://qix.it/~ludoo/archive/2004/05/python_logging_customization.html Another problem is that LogRecords are instantiated in Logger._log so it's difficult to customize __init__ behaviour for the LogRecord (and I argue that this is a useful thing).. b) A second problem is that the semantics of the log, info, debug, etc fns is a bit broken. Currently the defn looks like this: def debug(self, msg, *args, **kwargs): this suggests to me that a call like this is OK... logger.debug("here we go %(foo)s", foo = 'bar') but it's not. This is discussed further here... http://groups.google.com.au/group/comp.lang.python/browse_thread/thread/322919fcac0113ec/98ceaf6fc0c56881?lnk=st&q=python+logging+keywords&rnum=1#98ceaf6fc0c56881 Instead kwargs are used for customizing the behaviour of the debug method (e.g. exc_info, and extra). This seems i) a bit incongrous with its definition and therefore confusing, and ii) a bit of a hack (it's not completely insane though when you think about what's happening under the hood). Instead I propose using a couple of calls along the lines of printf/fprintf. In my world we'd have a simple printf-style function... def debug(self, msg, *args): and a more complex, more easily customizable fprintf-style one def x_debug(self, log_record, msg, *args): In these calls *args is a valid argument for the string formatting operator %, either a tuple of the right length or a dictionary. Any customization of the behaviour of the system can be done (using keyword args if you wish) in the log_record initializer (an example will follow). (Having said that perhaps we can check whether the first arg to the new simple debug() is a logrecord and if it is call the (hidden) extended version - that's more pythonic I imagine) c) This is not so much a feature request but a motivating mode of operation that I'd like to be able to use... Currently you can set up log filters. What you can filter is largely based on what information appears in the log record. It'd be nice to filter messages based on metadata that you add at log time (i.e. in the logger.debug(...) method). Currently it's quite painfull to set this up. This is because we can't customize the initialization of the log_record. The call structure in ii) above allows us to setup nice filtering mechanisms eg.. class GUIFilter: "A filter that only lets messges with gui tags through.""" def filter(self, log_record): return hasattr(log_record, 'gui') # set up a log, and a handler... log = logging.getLogger(..) file_handler = FileHandler(..) log.addHandler(file_handler) gui_msg_bar_handler = StreamHandler(..) log.addHandler(gui_msg_bar_handler) gui_msg_bar_handler.addFilter(GUIFilter()) # msg only goes to the file_handler log.debug("here we go %s", "here's an arg") # msg goes to the file_handler and to the gui_handler. log.x_debug(LogRecord(gui=True), "what you just tried to do didn't work %s", "fool") Change a) could be made with no backward compatability problems (I can see), change b) could be made without probs if you didn't overload the existing logging methods with the new ones, and then deprecate the existing ones (though what you'd call the new fns I don't know). That said I quite like the logger lib and I use it. It's a lot better than anything I would have thought up. cheers blaize ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2006-08-04 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Vinay Sajip (vsajip) Date: 2006-05-02 02:11 Message: Logged In: YES user_id=308438 Why does the recent introduction of the 'extra' keyword argument, meant to allow easily adding extra attributes to the LogRecord, not meet your use cases? The LogRecord is meant to be just a handy container and not have much logic (e.g. it needs to be serialised as XML, pickle etc.); why do you need to customise LogRecord.__init__? I didn't see an actual argument above for doing this, please point it out. It's also the case that the msg argument passed to a logging call need not be a string; it can be an arbitrary object on which str() is called at message formatting time to get the actual format string. So a custom object defining __str__ can return a customised message string. Perhaps I'm not seeing the use case you have in sufficient detail to understand why existing functionality does not meet your needs; please feel free to follow up with more detailed info. ---------------------------------------------------------------------- Comment By: blaize rhodes (blaize) Date: 2006-04-22 02:56 Message: Logged In: YES user_id=264689 For readability put an "if __name__ == '__main__':" above the # set up a log, and a handler... line. Sorry I didn't realize all my whitespace would get eaten rendering the code ambiguous. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1474577&group_id=5470 From noreply at sourceforge.net Sat Aug 5 08:19:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 23:19:56 -0700 Subject: [ python-Feature Requests-1534942 ] Print identical floats consistently Message-ID: Feature Requests item #1534942, was opened at 2006-08-05 06:19 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=1534942&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Submitted By: Marc W. Abel (gihon) Assigned to: Nobody/Anonymous (nobody) Summary: Print identical floats consistently Initial Comment: Hello again and thank you, This is a rewrite of now-closed bug #1534769. As you know, >>> print .1 >>> print (.1,) give different results because the __str__ call from print becomes a __repr__ call on the tuple, and it stays a __repr__ beneath that point in any recursion. >From the previous discussion, we need behavior like this so that strings are quoted inside tuples. I suggest that print use a third builtin that is neither __str__ nor __repr__. The name isn't important, but suppose we call it __strep__ in this feature request. __strep__ would pass __strep__ down in the recursion, printing floats with __str__ and everything else with __repr__. This would then >>> print .1 and >>> print (.1,) with the same precision. Marc ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1534942&group_id=5470 From noreply at sourceforge.net Sat Aug 5 08:24:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 04 Aug 2006 23:24:04 -0700 Subject: [ python-Bugs-1534769 ] Identical floats print inconsistently Message-ID: Bugs item #1534769, was opened at 2006-08-04 20:07 Message generated for change (Comment added) made by gihon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534769&group_id=5470 Please note that this 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: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Submitted By: Marc W. Abel (gihon) Assigned to: Nobody/Anonymous (nobody) Summary: Identical floats print inconsistently Initial Comment: Hi, and thank you. Many bugs relating to this have been submitted by others over a period of years, and these have generally been closed with "not a bug" responses. I'll do my best to explain the problem clearly enough. The following session prints a single variable three ways, with two different results: ----------- [me at localhost current]$ python Python 2.4.1 (#1, May 16 2005, 15:19:29) [GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a = round(1./7, 3) >>> print a 0.143 >>> print (a,) (0.14299999999999999,) >>> print (a,)[0] 0.143 >>> ----------- I'm fully informed about IEEE floating point representations in binary, but the limitations of data type are not causing the difference in output. The interpreter is using different rules to print this float, depending on whether it's a straight float or part of some other structure (in this example, a tuple). Once the interpreter recurses to a depth where it's clearly going to print a float, whatever rule is selected needs to be consistently applied. This means calling the same string formatting code with the same inputs. Marc ---------------------------------------------------------------------- >Comment By: Marc W. Abel (gihon) Date: 2006-08-05 06:24 Message: Logged In: YES user_id=789149 Hi Tim and Georg, Thanks for your kind replies. I've followed up with feature request 1534942, suggesting that print pass down __strep__, which passes itself down. __strep__ prints floats with __str__ and everything else with __rep__. Enjoy the weekend! I'll be writing a ray tracer.... Marc ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-08-04 21:24 Message: Logged In: YES user_id=31435 gbrandl is correct that the differences here are entirely due to the difference between float's __repr__ and __str__ methods. The reasons they /are/ different for floats are explained in the Tutorial's appendix on floating-point issues. It may be considered unfortunate that tuple.__repr__ is the same as tuple.__str__, and that both "pass repr down" to containees, but the reason for that has to do with the difference between str.__repr__ and str.__str__. If str(tuple) "passed str down" to containees, then, e.g., print ("a, bc", "de f,", "gh), i") would display the incomprehensibly confused: (a, bc, de f,, gh), i) IOW, it's actually the difference in what string types do that /drives/ the general decision that c.__str__ is the same as c.__repr__ for all objects `c` of container types, and that both "pass repr down" to containees. Alas, that's not always what people using strings want either :-) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-04 20:14 Message: Logged In: YES user_id=849994 Sorry, but this is another "not a bug". "print tuple" invokes tuple.__repr__() (because there is no separate __str__) which invokes repr(item) on each tuple item, while "print item" invokes str(item). For floats, this distinction results in a different rounding precision. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534769&group_id=5470 From noreply at sourceforge.net Sat Aug 5 12:01:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Aug 2006 03:01:36 -0700 Subject: [ python-Bugs-1519571 ] turtle.py Docs still incomplete Message-ID: Bugs item #1519571, was opened at 2006-07-09 14:49 Message generated for change (Comment added) made by gregorlingl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519571&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Lingl (gregorlingl) Assigned to: A.M. Kuchling (akuchling) Summary: turtle.py Docs still incomplete Initial Comment: There are three functions in turtle.py (which do not occur as methods of Pen), which are still not documented: setup() title() done() Regards, Gregor ---------------------------------------------------------------------- >Comment By: Lingl (gregorlingl) Date: 2006-08-05 10:01 Message: Logged In: YES user_id=1547199 The three functions setup(), title() done() DO NOT OCCUR as methods of Turtle, Pen, and RawPen. This should be mentioned in section 20.4.1 Turtle, Pen and RawPen Objects in the first paragraph in the except clause: Turtle, Pen and RawPen objects have all the global functions described above, except for demo() as methods, which manipulate the given pen. Regards, Gregor ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-07-29 14:46 Message: Logged In: YES user_id=11375 I've added documentation for these methods in rev. 50932. Thanks for pointing out the omission! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519571&group_id=5470 From noreply at sourceforge.net Sat Aug 5 13:18:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Aug 2006 04:18:19 -0700 Subject: [ python-Bugs-1519452 ] zipfile -- too many files? Message-ID: Bugs item #1519452, was opened at 2006-07-09 05:57 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Joe Brown (shmengie) Assigned to: Nobody/Anonymous (nobody) Summary: zipfile -- too many files? Initial Comment: While creating a huge zipfile (probably too big) the following error appeared. Exception exceptions.OverflowError: 'long int too large to convert to int' in > ignored I assume this is during the closing of the zipfile, further assuming too many files were added to the archive. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-13 08:17 Message: Logged In: YES user_id=580910 hmm, I should read all new comments before responding :-( To use the ZIP64 extensions with python2.5 you must add 'allowZip64=True' to arguments of the zipfile constructor. ZIP64 is disabled by default because the unix zip tools don't support zip64. ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-13 07:47 Message: Logged In: YES user_id=580910 The problem with zipfile is not the number of files, but the size of the archive. The basic zip file format stores file sizes as 32 bit (signed) integers, there is an extension for using 64 bit integers, but that isn't supported in python 2.4. ---------------------------------------------------------------------- Comment By: Joe Brown (shmengie) Date: 2006-07-12 02:17 Message: Logged In: YES user_id=729883 Windows 2.5 beta 2 responded like this: Traceback (most recent call last): File "C:\python_scripts\archive.py", line 27, in main() File "C:\python_scripts\archive.py", line 23, in main zipper(zip, folder) File "C:\python_scripts\archive.py", line 15, in zipper zip.write(os.path.join(root, item)) File "C:\Python25\lib\zipfile.py", line 561, in write self._writecheck(zinfo) File "C:\Python25\lib\zipfile.py", line 536, in _writecheck raise LargeZipFile("Zipfile size would require ZIP64 extensions") zipfile.LargeZipFile: Zipfile size would require ZIP64 extensions C:\Python25\lib\struct.py:63: DeprecationWarning: struct integer overflow maskin g is deprecated return o.pack(*args) ---------------------------------------------------------------------- Comment By: Joe Brown (shmengie) Date: 2006-07-11 20:08 Message: Logged In: YES user_id=729883 The zip file was on order of 6-9 GBs, surely over 32000 files. I will give Python2.5 a shot and see how that works. I've stumbled on another bug with tarfile. It's not reporting an error, but I only find 350 files when I unarchive. That's entirely different bug tho :-o ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-11 17:47 Message: Logged In: YES user_id=580910 How large is the resulting file? Zipfile in python2.4 cannot handle zipfiles that require the zip64 extensions and fails misserably when you do cross that limit. This was fixed in python 2.5. ---------------------------------------------------------------------- Comment By: Joe Brown (shmengie) Date: 2006-07-09 06:01 Message: Logged In: YES user_id=729883 Platform: Windows SBS 2003 Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519452&group_id=5470 From noreply at sourceforge.net Sat Aug 5 17:56:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Aug 2006 08:56:58 -0700 Subject: [ python-Bugs-1295179 ] termios.c in qnx4.25 Message-ID: Bugs item #1295179, was opened at 2005-09-19 17:28 Message generated for change (Comment added) made by kbob_ru You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295179&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific Status: Closed Resolution: None Priority: 5 Submitted By: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: termios.c in qnx4.25 Initial Comment: I compile python version 2.3.5 in QNX4.25. But I found that #include don't work because in qnx4 we need to include first in which #include already present. Second, Module/termios.c needs flag IXANY, that not defined in qnx4 headers. Include right header and write #ifdef IXANY \ #endif around helps to compile Module/termios.c. ---------------------------------------------------------------------- >Comment By: kbob_ru (kbob_ru) Date: 2006-08-05 23:56 Message: Logged In: YES user_id=1347065 Now I have patch for Python-2.5b3 ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-07-18 10:21 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-03 21:40 Message: Logged In: YES user_id=849994 Can you test this with Python 2.5b1? ---------------------------------------------------------------------- Comment By: kbob_ru (kbob_ru) Date: 2006-06-03 13:03 Message: Logged In: YES user_id=1347065 I used next patch for Python versions 2.3.5 and 2.4.3. It helps work properly termios module in QNX4.25 and termios test pass. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295179&group_id=5470 From noreply at sourceforge.net Sat Aug 5 18:01:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Aug 2006 09:01:57 -0700 Subject: [ python-Bugs-1535081 ] can't staticaly build modules md5 and sha Message-ID: Bugs item #1535081, was opened at 2006-08-06 00: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=1535081&group_id=5470 Please note that this 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: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: can't staticaly build modules md5 and sha Initial Comment: When build Python-2.5b3 I find that function initsha(void) in shamodule.c in Python-2.4.3 renamed to init_sha(void) in Python-2.5b3 but in Setup I just find old rule for static building sha module. This looks like sha shamodule.c Same thing with md5 module too. init_md5(void) in Python-2.5b3 but initmd5(void) in Python-2.4.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535081&group_id=5470 From noreply at sourceforge.net Sat Aug 5 19:33:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Aug 2006 10:33:31 -0700 Subject: [ python-Bugs-788035 ] missing universal newline support in os.popen & friends Message-ID: Bugs item #788035, was opened at 2003-08-13 15:17 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788035&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Torsten Marek (shlomme) Assigned to: Nobody/Anonymous (nobody) Summary: missing universal newline support in os.popen & friends Initial Comment: In contrast to the documentation, os.popen and relatives do not support the "U" format character in their constructors. os.popen("some_nifty_command some_arg", "rU") throws OSError: [Errno 22] Invalid argument , while os.popen{2,3,4} just ignores "U". I noticed that behaviour while p-opening oggenc (the ogg vorbis encoder), which uses curses for output. The lines end with \r and not with \n (due to some ncurses internals, I suspect), so that the file objects readline() function cannot split the output. ---------------------------------------------------------------------- >Comment By: Peter ?strand (astrand) Date: 2006-08-05 19:33 Message: Logged In: YES user_id=344921 Closing, as suggested by akuchling. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 22:50 Message: Logged In: YES user_id=11375 popen5 was added to Python 2.4 as the subprocess module. It's probably unlikely that someone will go back and fix the low-level os.popen2() function. I suggest that this bug be closed, and we encourage people to use the subprocess module. ---------------------------------------------------------------------- Comment By: Philip Lindsay (philiplindsay) Date: 2004-01-13 11:46 Message: Logged In: YES user_id=254205 See http://advogato.org/person/follower/diary.html?start=43 for details of a possible interim work around. (WFM, YMMV) ---------------------------------------------------------------------- Comment By: Philip Lindsay (philiplindsay) Date: 2004-01-13 11:45 Message: Logged In: YES user_id=254205 See for details of a possible interim work around. (WFM, YMMV) ---------------------------------------------------------------------- Comment By: Peter ?strand (astrand) Date: 2003-11-03 21:01 Message: Logged In: YES user_id=344921 I've added universal newline support to popen5. http://www.lysator.liu.se/~astrand/popen5/. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-08-27 00:04 Message: Logged In: YES user_id=45365 Theoretically this is easy to fix: if mode=="U" or "rU" just pass "r" to popen(), "rb" to fdopen() and _O_BINARY to the lowlevel calls, and the original string to PyFile_FromFile. But this whole popen{,2,3,4} section of posixmodule.c is so fiendishly complicated with all the platform special cases that I'm loath to touch it... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788035&group_id=5470 From noreply at sourceforge.net Sat Aug 5 22:47:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Aug 2006 13:47:22 -0700 Subject: [ python-Bugs-1535165 ] python segfaults when reading from closed stdin Message-ID: Bugs item #1535165, was opened at 2006-08-05 22: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=1535165&group_id=5470 Please note that this 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: Patrick Mezard (trickos) Assigned to: Nobody/Anonymous (nobody) Summary: python segfaults when reading from closed stdin Initial Comment: """" Python 2.5b3 (r25b3:51041, Aug 3 2006, 09:35:06) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.stdin.close() >>> raw_input() """ segfaults on Windows XP. Same thing happen with Python 2.4.2 (Build 248). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535165&group_id=5470 From noreply at sourceforge.net Sun Aug 6 00:22:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 05 Aug 2006 15:22:47 -0700 Subject: [ python-Bugs-1535182 ] typo in test_bz2.py Message-ID: Bugs item #1535182, was opened at 2006-08-06 00: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=1535182&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Submitted By: Lawrence Oluyede (rhymes) Assigned to: Nobody/Anonymous (nobody) Summary: typo in test_bz2.py Initial Comment: I've found a test passing but someone missed an 'x' at the end of the test. It's "xlines" not "lines" again because you're testing the xreadlines() method. I've attached the svn diff. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535182&group_id=5470 From noreply at sourceforge.net Sun Aug 6 09:01:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Aug 2006 00:01:20 -0700 Subject: [ python-Bugs-1295179 ] termios.c in qnx4.25 Message-ID: Bugs item #1295179, was opened at 2005-09-19 09:28 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295179&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Platform-specific >Status: Open Resolution: None Priority: 5 Submitted By: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: termios.c in qnx4.25 Initial Comment: I compile python version 2.3.5 in QNX4.25. But I found that #include don't work because in qnx4 we need to include first in which #include already present. Second, Module/termios.c needs flag IXANY, that not defined in qnx4 headers. Include right header and write #ifdef IXANY \ #endif around helps to compile Module/termios.c. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-06 07:01 Message: Logged In: YES user_id=849994 Okay, reopening. ---------------------------------------------------------------------- Comment By: kbob_ru (kbob_ru) Date: 2006-08-05 15:56 Message: Logged In: YES user_id=1347065 Now I have patch for Python-2.5b3 ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-07-18 02:21 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-03 13:40 Message: Logged In: YES user_id=849994 Can you test this with Python 2.5b1? ---------------------------------------------------------------------- Comment By: kbob_ru (kbob_ru) Date: 2006-06-03 05:03 Message: Logged In: YES user_id=1347065 I used next patch for Python versions 2.3.5 and 2.4.3. It helps work properly termios module in QNX4.25 and termios test pass. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1295179&group_id=5470 From noreply at sourceforge.net Sun Aug 6 09:08:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Aug 2006 00:08:23 -0700 Subject: [ python-Bugs-1535182 ] typo in test_bz2.py Message-ID: Bugs item #1535182, was opened at 2006-08-05 22:22 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535182&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Lawrence Oluyede (rhymes) Assigned to: Nobody/Anonymous (nobody) Summary: typo in test_bz2.py Initial Comment: I've found a test passing but someone missed an 'x' at the end of the test. It's "xlines" not "lines" again because you're testing the xreadlines() method. I've attached the svn diff. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-06 07:08 Message: Logged In: YES user_id=849994 Thanks, fixed in rev. 51126, 51127. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535182&group_id=5470 From noreply at sourceforge.net Sun Aug 6 09:10:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Aug 2006 00:10:50 -0700 Subject: [ python-Bugs-1522046 ] RPM build fails for Py2.5b2 Message-ID: Bugs item #1522046, was opened at 2006-07-13 21:55 Message generated for change (Comment added) made by scoder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522046&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Stefan Behnel (scoder) Assigned to: Nobody/Anonymous (nobody) Summary: RPM build fails for Py2.5b2 Initial Comment: Using Misc/RPM/python-2.5.spec, Python 2.5b2 fails to compile into an RPM on my machine (SuSE 10.1, AMD64, gcc 4.1). Unlike with b1, I get loads of errors saying: "ld: cannot find -lpython2.5" The funny thing is that it continues to build and only fails at the end when collecting the files for the RPM. I use configure --enable-shared --enable-unicode=ucs4 \ --enable-ipv6 --with-pymalloc --prefix=/usr \ --libdir=/usr/lib64 The shared library is correctly built before these errors come up. The error appear on the "sharedmods" target. I also tried setting LD_LIBRARY_PATH by hand, although the build script sets it before starting to build the modules - no help. What *does* help is adding "-L." to the LDFLAGS in Makefile.pre.in: sed -e '/DIR=.*lib$/ s|/lib$|/%{libdirname}| ; \ /LDFLAGS/ s|LDFLAGS=|LDFLAGS= -L. |' \ ./Makefile.pre.in.old >Makefile.pre.in The "DIR=" is for an x86_64 bug that installs Python to the wrong directory (/usr/lib instead of /usr/lib64). I tried building Py2.5 by hand (configure/make) and that also works nicely. I attached a patch that fixes the problems I encountered. ---------------------------------------------------------------------- >Comment By: Stefan Behnel (scoder) Date: 2006-08-06 09:10 Message: Logged In: YES user_id=313935 The linking is fixed in 2.5b3. However, the /usr/lib64 problem remains. Python is installed to lib64 on my AMD64 machine, but the import mechanism keeps looking in /usr/lib. ---------------------------------------------------------------------- Comment By: Eric Wald (breadman) Date: 2006-08-04 22:22 Message: Logged In: YES user_id=324500 Seems to be fixed in 2.5b3. ---------------------------------------------------------------------- Comment By: Eric Wald (breadman) Date: 2006-08-03 22:12 Message: Logged In: YES user_id=324500 There is a deeper issue here: Dynamic extensions fail to link until after libpython2.5.so.1.0 is installed. The '-L.' flag is the better approach to fixing this bug, but perhaps it should use the full path name, like the LD_LIBRARY_PATH environment variable used when running setup.py. Unfortunately, this bug is hidden from people compiling on top of an earlier 2.5 installation, where the link step will find and use the old library; for others, it is resolved in installation, where make will happily link the extensions if they failed to link earlier, right after installing the library. However, it means that the dynamic libraries are unavailable between the build and install steps. One major result is that the test suite refuses to run at that time. It also means that 'make install' can cause the linker to be called, which is generally discouraged. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1522046&group_id=5470 From noreply at sourceforge.net Sun Aug 6 09:26:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Aug 2006 00:26:48 -0700 Subject: [ python-Bugs-1535081 ] can't staticaly build modules md5 and sha Message-ID: Bugs item #1535081, was opened at 2006-08-05 16:01 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535081&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: kbob_ru (kbob_ru) Assigned to: Nobody/Anonymous (nobody) Summary: can't staticaly build modules md5 and sha Initial Comment: When build Python-2.5b3 I find that function initsha(void) in shamodule.c in Python-2.4.3 renamed to init_sha(void) in Python-2.5b3 but in Setup I just find old rule for static building sha module. This looks like sha shamodule.c Same thing with md5 module too. init_md5(void) in Python-2.5b3 but initmd5(void) in Python-2.4.3. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-06 07:26 Message: Logged In: YES user_id=849994 Fixed in rev. 51128. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535081&group_id=5470 From noreply at sourceforge.net Sun Aug 6 10:24:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Aug 2006 01:24:15 -0700 Subject: [ python-Bugs-1535165 ] python segfaults when reading from closed stdin Message-ID: Bugs item #1535165, was opened at 2006-08-05 20:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535165&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Patrick Mezard (trickos) Assigned to: Nobody/Anonymous (nobody) Summary: python segfaults when reading from closed stdin Initial Comment: """" Python 2.5b3 (r25b3:51041, Aug 3 2006, 09:35:06) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.stdin.close() >>> raw_input() """ segfaults on Windows XP. Same thing happen with Python 2.4.2 (Build 248). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-06 08:24 Message: Logged In: YES user_id=849994 Thanks for the report, fixed raw_input() and input() in rev. 51129, 51130 (2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535165&group_id=5470 From noreply at sourceforge.net Sun Aug 6 21:38:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Aug 2006 12:38:01 -0700 Subject: [ python-Bugs-1535502 ] Python 2.5 windows builds should link hashlib with OpenSSL Message-ID: Bugs item #1535502, was opened at 2006-08-06 12:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535502&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Gregory P. Smith (greg) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5 windows builds should link hashlib with OpenSSL Initial Comment: The Windows builds of Python 2.5 need to be updated to build and link the hashlib modules with OpenSSL 0.9.8. The OpenSSL implementations of the hash algorithms are *much* faster (often 2-3x) than the fallback C implementations that python includes for use when OpenSSL isn't available. I just tested the python 2.5b3 installer on windows. its using the fallback versions rather than OpenSSL: here's a simple way to check from a running python: Without OpenSSL: >>> import hashlib >>> hashlib.sha1 With OpenSSL: >>> import hashlib >>> hashlib.sha1 (please use openssl 0.9.8; older versions don't include sha256 and sha512 implementations) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535502&group_id=5470 From noreply at sourceforge.net Sun Aug 6 21:41:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Aug 2006 12:41:48 -0700 Subject: [ python-Bugs-1526834 ] unbalanced parentheses from command line crash pdb Message-ID: Bugs item #1526834, was opened at 2006-07-21 21:03 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526834&group_id=5470 Please note that this 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: Ilya Sandler (isandler) Assigned to: A.M. Kuchling (akuchling) Summary: unbalanced parentheses from command line crash pdb Initial Comment: bagira:~/python-svn/patches> cat simple print 123 bagira:~/python-svn/patches> ../python/trunk/python -m pdb simple (Pdb) b f( #crashes your program Traceback (most recent call last): ... File "/home/ilya/python-svn/python/trunk/Lib/sre.py", line 233, in _compile raise error, v # invalid expression error: unbalanced parenthesis Uncaught exception. Entering post mortem debugging (Pdb) b f( # doing it post-mortem fully crashes pdb Traceback (most recent call last): .. raise error, v # invalid expression sre_constants.error: unbalanced parenthesis bagira:~/python-svn/patches> ---------------------------------------------------------------------- >Comment By: Ilya Sandler (isandler) Date: 2006-08-06 12:41 Message: Logged In: YES user_id=971153 I don't think supporting "b f()" is needed... And as a catch-all argument, gdb does not support "b f()" either ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-07-27 05:38 Message: Logged In: YES user_id=11375 Easily fixed by adding a re.escape() call, but this means that 'b f()', if you've been doing that, will no longer work to set a breakpoint. The documentation doesn't claim that 'b f()' should work, but people may be used to typing this. I've asked the 2.5 release manager about this issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526834&group_id=5470 From noreply at sourceforge.net Sun Aug 6 21:45:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Aug 2006 12:45:17 -0700 Subject: [ python-Bugs-1436206 ] CGIHTTPServer doesn't handle path names with embeded space Message-ID: Bugs item #1436206, was opened at 2006-02-21 22:56 Message generated for change (Comment added) made by htgoebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436206&group_id=5470 Please note that this 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: Richard Coupland (rick-eci) Assigned to: Nobody/Anonymous (nobody) Summary: CGIHTTPServer doesn't handle path names with embeded space Initial Comment: On Windows, if the path name of a CGI script to be run contains one or more space characters, the path name is split into multiple parameters causing an error. I have not tried not tried this on other platforms. ---------------------------------------------------------------------- Comment By: Hartmut Goebel (htgoebel) Date: 2006-08-06 21:45 Message: Logged In: YES user_id=376953 I just submitted a patch for this. see patch #1535504. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436206&group_id=5470 From noreply at sourceforge.net Mon Aug 7 00:13:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Aug 2006 15:13:00 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 04:47 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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: 9 Submitted By: nomind (vnainar) Assigned to: A.M. Kuchling (akuchling) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-06 18:12 Message: Logged In: YES user_id=11375 Committed to the trunk in rev. 51134. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 08:53 Message: Logged In: YES user_id=11375 Sure. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-03 02:03 Message: Logged In: YES user_id=33168 Andrew, could you apply this after the freeze is over? ---------------------------------------------------------------------- Comment By: Paul Smedley (psmedley) Date: 2006-05-21 10:38 Message: Logged In: YES user_id=1359962 I have a similar problem on OS/2. When running any script that uses curses I get: [U:\dev\Python-2.4.3\PC\os2emx]python test_curses.py Traceback (most recent call last): File "test_curses.py", line 242, in ? curses.wrapper(main) File "U:/DEV/PYTHON-2.4.3/Lib/curses/wrapper.py", line 49, in wrapper curses.nocbreak() _curses.error: nocbreak() returned ERR If I remove the reference to nocbreak() from wrapper.py, I get the same error but in endwin(), removing endwin() from wrapper.py, I get an error in cbreak(), removing cbreak() then some scripts work. For example, from the demo folder, all work exceptlife.py & xmas.py, which both return an error "_curses.error: nocbreak() returned ERR" on various line numbers. Seems certain curses functions are working correctly, others aren't. The patch in this bug does NOT make any difference here. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-17 14:50 Message: Logged In: YES user_id=1497957 /me confirms ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-15 11:30 Message: Logged In: YES user_id=21627 Good spotting! Can everybody please confirm that the attached patch fixes the problem? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-15 10:48 Message: Logged In: YES user_id=1497957 Half day of debugging and it seems that I found an answer... just by accident ;). When curses module is linked against ncursesw it seems that it also should be linked against panelw not plain panel. After changing this in setup.py, ncurses.py demo finally runs fine. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-15 03:05 Message: Logged In: YES user_id=21627 I couldn't reproduce the problem on a Linux console (although my console had a different size); so it remains unreproducable for me. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-13 07:00 Message: Logged In: YES user_id=1493752 Well , it is the linux console (in VGA mode ). The local is en_US.The size of the console is 100X37. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-11 01:32 Message: Logged In: YES user_id=21627 Ah, ok. vnainar, atler_: What terminal had you been using to make it crash? What is your locale? Any other conditions that might be relevant (e.g. dimension of the terminal)? ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-11 01:13 Message: Logged In: YES user_id=1493752 Removing 'ncursesw' (there are two references to it in 'setup.py') seems to solve the problem. I noticed one more oddity. Even before the above recompilation , it ran fine on an Xterm ! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-10 18:28 Message: Logged In: YES user_id=21627 That's hard to tell. Somebody would have to debug ncurses to find out why it crashes. Notice that it crashes only on some installations, so it is likely rather a problem with your ncurses installation, than with Python (or even with ncurses itself). ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-10 17:24 Message: Logged In: YES user_id=1497957 loewis: removing lines refering to ncursesw solves the problem. ncurses.py runs fine as well as other programs. What is actual problem then? Something with ncursesw or with python? Anyway, Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-09 16:58 Message: Logged In: YES user_id=21627 atler_: around line 427, you find if self.compiler.find_library_file(lib_dirs, 'ncursesw'): readline_libs.append('ncursesw') elif self.compiler.find_library_file(lib_dirs, 'ncurses'): Replace that with if self.compiler.find_library_file(lib_dirs, 'ncurses'): (i.e. dropping the ncursesw part), and rebuild. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 09:48 Message: Logged In: YES user_id=1497957 More complete backtrace, I hope it will help: http://pastebin.com/649445 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 08:14 Message: Logged In: YES user_id=29957 The buildbot boxes don't show this problem. You might need to rebuild a Python with -g and unstripped to get a useful backtrace. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 06:51 Message: Logged In: YES user_id=1497957 $ ldd /usr/lib/python2.4/lib-dynload/_curses.so libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x7004c000) libpthread.so.0 => /lib/libpthread.so.0 (0x70080000) libc.so.6 => /lib/libc.so.6 (0x700e4000) libdl.so.2 => /lib/libdl.so.2 (0x70228000) libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000) /lib/ld-linux.so.2 (0x70000000) ... Program received signal SIGSEGV, Segmentation fault. 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 gdb) bt #0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 #1 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so #2 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so Previous frame identical to this frame (corrupt stack?) It seems that only programs using panel library cause segfaults (all other demos run fine except ncurses.py), sorry for a mistake in a last post. loewis: I'm not sure I understand second point. What excatly should be changed in setup.py? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-09 06:46 Message: Logged In: YES user_id=1126061 Cannot reproduce on Gentoo. All the files in the Demo/curses directory run fine. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-09 06:29 Message: Logged In: YES user_id=21627 I can't reproduce any of this on Debian; Demo/curses/ncurses.py runs fine. Can you please 1. run ldd on _curses.so, and report the output, and 2. edit setup.py, removing the lines that deal with ncursesw, 3. atler_: produce a gdb backtrace on the time of the crash, 4: vnainar: please report what you mean by "does not work". Does it erase your hard disk? turn off the machine? Paint things blue instead of red? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 06:06 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-06 01:38 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-04 18:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Mon Aug 7 02:39:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Aug 2006 17:39:31 -0700 Subject: [ python-Bugs-1464056 ] curses library in python 2.4.3 broken Message-ID: Bugs item #1464056, was opened at 2006-04-04 04:47 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 Please note that this 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: 9 Submitted By: nomind (vnainar) Assigned to: A.M. Kuchling (akuchling) Summary: curses library in python 2.4.3 broken Initial Comment: My python programs using curses library do not work with version 2.4.3.Even the 'ncurses.py ' demo program in the Demo/curses directory does not work correctly. The problem seems to be in the 'panels' library ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-06 20:39 Message: Logged In: YES user_id=11375 Committed to 2.4 branch in rev.51136. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-06 18:12 Message: Logged In: YES user_id=11375 Committed to the trunk in rev. 51134. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 08:53 Message: Logged In: YES user_id=11375 Sure. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-03 02:03 Message: Logged In: YES user_id=33168 Andrew, could you apply this after the freeze is over? ---------------------------------------------------------------------- Comment By: Paul Smedley (psmedley) Date: 2006-05-21 10:38 Message: Logged In: YES user_id=1359962 I have a similar problem on OS/2. When running any script that uses curses I get: [U:\dev\Python-2.4.3\PC\os2emx]python test_curses.py Traceback (most recent call last): File "test_curses.py", line 242, in ? curses.wrapper(main) File "U:/DEV/PYTHON-2.4.3/Lib/curses/wrapper.py", line 49, in wrapper curses.nocbreak() _curses.error: nocbreak() returned ERR If I remove the reference to nocbreak() from wrapper.py, I get the same error but in endwin(), removing endwin() from wrapper.py, I get an error in cbreak(), removing cbreak() then some scripts work. For example, from the demo folder, all work exceptlife.py & xmas.py, which both return an error "_curses.error: nocbreak() returned ERR" on various line numbers. Seems certain curses functions are working correctly, others aren't. The patch in this bug does NOT make any difference here. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-17 14:50 Message: Logged In: YES user_id=1497957 /me confirms ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-15 11:30 Message: Logged In: YES user_id=21627 Good spotting! Can everybody please confirm that the attached patch fixes the problem? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-15 10:48 Message: Logged In: YES user_id=1497957 Half day of debugging and it seems that I found an answer... just by accident ;). When curses module is linked against ncursesw it seems that it also should be linked against panelw not plain panel. After changing this in setup.py, ncurses.py demo finally runs fine. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-15 03:05 Message: Logged In: YES user_id=21627 I couldn't reproduce the problem on a Linux console (although my console had a different size); so it remains unreproducable for me. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-13 07:00 Message: Logged In: YES user_id=1493752 Well , it is the linux console (in VGA mode ). The local is en_US.The size of the console is 100X37. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-11 01:32 Message: Logged In: YES user_id=21627 Ah, ok. vnainar, atler_: What terminal had you been using to make it crash? What is your locale? Any other conditions that might be relevant (e.g. dimension of the terminal)? ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-11 01:13 Message: Logged In: YES user_id=1493752 Removing 'ncursesw' (there are two references to it in 'setup.py') seems to solve the problem. I noticed one more oddity. Even before the above recompilation , it ran fine on an Xterm ! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-10 18:28 Message: Logged In: YES user_id=21627 That's hard to tell. Somebody would have to debug ncurses to find out why it crashes. Notice that it crashes only on some installations, so it is likely rather a problem with your ncurses installation, than with Python (or even with ncurses itself). ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-10 17:24 Message: Logged In: YES user_id=1497957 loewis: removing lines refering to ncursesw solves the problem. ncurses.py runs fine as well as other programs. What is actual problem then? Something with ncursesw or with python? Anyway, Thanks for your help. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-09 16:58 Message: Logged In: YES user_id=21627 atler_: around line 427, you find if self.compiler.find_library_file(lib_dirs, 'ncursesw'): readline_libs.append('ncursesw') elif self.compiler.find_library_file(lib_dirs, 'ncurses'): Replace that with if self.compiler.find_library_file(lib_dirs, 'ncurses'): (i.e. dropping the ncursesw part), and rebuild. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 09:48 Message: Logged In: YES user_id=1497957 More complete backtrace, I hope it will help: http://pastebin.com/649445 ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-04-09 08:14 Message: Logged In: YES user_id=29957 The buildbot boxes don't show this problem. You might need to rebuild a Python with -g and unstripped to get a useful backtrace. ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 06:51 Message: Logged In: YES user_id=1497957 $ ldd /usr/lib/python2.4/lib-dynload/_curses.so libncursesw.so.5 => /usr/lib/libncursesw.so.5 (0x7004c000) libpthread.so.0 => /lib/libpthread.so.0 (0x70080000) libc.so.6 => /lib/libc.so.6 (0x700e4000) libdl.so.2 => /lib/libdl.so.2 (0x70228000) libtinfow.so.5 => /usr/lib/libtinfow.so.5 (0x7023c000) /lib/ld-linux.so.2 (0x70000000) ... Program received signal SIGSEGV, Segmentation fault. 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 gdb) bt #0 0x7063947c in hide_panel () from /usr/lib/libpanel.so.5 #1 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so #2 0x706254b8 in ?? () from /usr/lib/python2.4/lib-dynload/_curses_panel.so Previous frame identical to this frame (corrupt stack?) It seems that only programs using panel library cause segfaults (all other demos run fine except ncurses.py), sorry for a mistake in a last post. loewis: I'm not sure I understand second point. What excatly should be changed in setup.py? ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-04-09 06:46 Message: Logged In: YES user_id=1126061 Cannot reproduce on Gentoo. All the files in the Demo/curses directory run fine. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-09 06:29 Message: Logged In: YES user_id=21627 I can't reproduce any of this on Debian; Demo/curses/ncurses.py runs fine. Can you please 1. run ldd on _curses.so, and report the output, and 2. edit setup.py, removing the lines that deal with ncursesw, 3. atler_: produce a gdb backtrace on the time of the crash, 4: vnainar: please report what you mean by "does not work". Does it erase your hard disk? turn off the machine? Paint things blue instead of red? ---------------------------------------------------------------------- Comment By: Jan Palus (atler_) Date: 2006-04-09 06:06 Message: Logged In: YES user_id=1497957 I confirm the problem. Every program using curses library segfaults and there's only one error before it happens: ... import curses # directory /usr/share/python2.4/curses import curses # precompiled from /usr/share/python2.4/curses/__init__.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses.so", 2); import _curses # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses.so import curses.wrapper # precompiled from /usr/share/python2.4/curses/wrapper.pyc import curses.panel # precompiled from /usr/share/python2.4/curses/panel.pyc dlopen("/usr/lib/python2.4/lib-dynload/_curses_panel.so", 2); import _curses_panel # dynamically loaded from /usr/lib/python2.4/lib-dynload/_curses_panel.so Traceback (most recent call last): File "ncurses.py", line 273, in ? curses.wrapper(demo_panels) File "/usr/share/python2.4/curses/wrapper.py", line 49, in wrapper _curses.error: nocbreak() returned ERR I'm running Linux (PLD) with Python 2.4.3 and ncurses 5.5. With Python 2.4.2 everything worked fine. ---------------------------------------------------------------------- Comment By: nomind (vnainar) Date: 2006-04-06 01:38 Message: Logged In: YES user_id=1493752 Sorry my original post was incomplete. I am running slackware 10.2 (linux kernel 2.6).The python library was tested with ncurses 5.4 and ncurses 5.5( the latest release). All programs run OK with 2.4.1.As I said ,the curses demo that comes with the Python distributions runs OK with 2.4.1 but not with 2.4.3 - I have both on my machine ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-04 18:16 Message: Logged In: YES user_id=21627 What do you mean by "do not work"? What operating system and what curses implementation are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1464056&group_id=5470 From noreply at sourceforge.net Mon Aug 7 07:50:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Aug 2006 22:50:53 -0700 Subject: [ python-Bugs-1112549 ] cgi.FieldStorage memory usage can spike in line-oriented ops Message-ID: Bugs item #1112549, was opened at 2005-01-30 05:40 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 Please note that this 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: 8 Submitted By: Chris McDonough (chrism) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.FieldStorage memory usage can spike in line-oriented ops Initial Comment: Various parts of cgi.FieldStorage call its "read_lines_to_outerboundary", "read_lines" and "skip_lines" methods. These methods use the "readline" method of the file object that represents an input stream. The input stream is typically data supplied by an untrusted source (such as a user uploading a file from a web browser). The input data is not required by the RFC 822/1521/1522/1867 specifications to contain any newline characters. For example, it is within the bounds of the specification to supply a a multipart/form-data input stream with a "file-data" part that consists of a 2GB string composed entirely of "x" characters (which happens to be something I did that led me to noticing this bug). The simplest fix is to make use of the "size" argument of the readline method of the file object where it is used within all parts of FieldStorage that make use of it. A patch against the Python 2.3.4 cgi.py module that does this is attached. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-06 22:50 Message: Logged In: YES user_id=33168 Doesn't this require a change to test/output/test_cgi or something like that? Does this test pass when run under regrtest.py ? The verify(x == y) should be vereq(x, y). type(a) != type(0), should be not isinstance(a, int). The last chunk of the patch in cgi.py should be: last_line_lfend = line.endswith('\n') rather than the 4 lines of if/else. I don't know if this patch really addresses the problem or creates other problems. However, if someone more knowledgable is confident about this patch, I'm fine with this going in. At this point, it might be better to wait for 2.5.1 though. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-07-27 14:42 Message: Logged In: YES user_id=32974 The files I've just uploaded are revisions to the cgi and test_cgi modules for the current state of the SVN trunk. If someone could apply these, it would be appreciated, or give me access and I'll be happy to. FTR, this is a bug which exposes systems which use the cgi.FieldStorage class (most Python web frameworks do) to a denial of service potential. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-02 20:00 Message: Logged In: YES user_id=32974 FYI, I'd be happy to do the merging here if you wanted to give me checkin access. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-02 19:42 Message: Logged In: YES user_id=32974 An updated test_cgi.py is attached. I test both the readline behavior and add a test for basic multipart parsing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 20:48 Message: Logged In: YES user_id=6380 Can I tweak you into uploading a unit test? ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-03-31 18:56 Message: Logged In: YES user_id=32974 Re: parse_multipart.. yes, it looks like there's no use fixing that as it just turns around and puts the line into a list.. it is vulnerable but just by virtue of its non-use of a tempfile, it appears doomed anyway for large requests. I don't know of anything that uses it. Good catch wrt boundary recognition bug, I'm uploading another patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 14:13 Message: Logged In: YES user_id=6380 Methinks that the fix isn't quite right: it would incorrectly recognize as a boundary a very long line starting with "--" followed by the appropriate random string at offset 2**16. This could probably be taken care of by adding a flag that is true initially and after that keeps track of whether the previous line ended in \n. Also, there's a call to fp.readline() in parse_multipart() that you didn't patch -- it wouldn't help because that code is saving the lines in a list anyway, but isn't that code vulnerable as well? Or is it not used? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 From noreply at sourceforge.net Mon Aug 7 16:21:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Aug 2006 07:21:37 -0700 Subject: [ python-Bugs-1536021 ] hash(method) sometimes raises OverflowError Message-ID: Bugs item #1536021, was opened at 2006-08-07 14:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536021&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Christian Tanzer (tanzer) Assigned to: Nobody/Anonymous (nobody) Summary: hash(method) sometimes raises OverflowError Initial Comment: I've run into a problem with a big application that I wasn't able to reproduce with a small example. The code (exception handler added to demonstrate and work around the problem): try : h = hash(p) except OverflowError, e: print type(p), p, id(p), e h = id(p) & 0x0FFFFFFF prints the following output: > 3066797028 long int too large to convert to int This happens with Python 2.5b3, but didn't happen with Python 2.4.3. I assume that the hash-function for function/methods returns the `id` of the function. The following code demonstrates the same problem with a Python class whose `__hash__` returns the `id` of the object: $ python2.4 Python 2.4.3 (#1, Jun 30 2006, 10:02:59) [GCC 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X(object): ... def __hash__(self): return id(self) ... >>> hash (X()) -1211078036 $ python2.5 Python 2.5b3 (r25b3:51041, Aug 7 2006, 15:35:35) [GCC 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X(object): ... def __hash__(self): return id(self) ... >>> hash (X()) Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536021&group_id=5470 From noreply at sourceforge.net Mon Aug 7 17:03:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Aug 2006 08:03:25 -0700 Subject: [ python-Bugs-1536021 ] hash(method) sometimes raises OverflowError Message-ID: Bugs item #1536021, was opened at 2006-08-08 00:21 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536021&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Christian Tanzer (tanzer) Assigned to: Nobody/Anonymous (nobody) Summary: hash(method) sometimes raises OverflowError Initial Comment: I've run into a problem with a big application that I wasn't able to reproduce with a small example. The code (exception handler added to demonstrate and work around the problem): try : h = hash(p) except OverflowError, e: print type(p), p, id(p), e h = id(p) & 0x0FFFFFFF prints the following output: > 3066797028 long int too large to convert to int This happens with Python 2.5b3, but didn't happen with Python 2.4.3. I assume that the hash-function for function/methods returns the `id` of the function. The following code demonstrates the same problem with a Python class whose `__hash__` returns the `id` of the object: $ python2.4 Python 2.4.3 (#1, Jun 30 2006, 10:02:59) [GCC 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X(object): ... def __hash__(self): return id(self) ... >>> hash (X()) -1211078036 $ python2.5 Python 2.5b3 (r25b3:51041, Aug 7 2006, 15:35:35) [GCC 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X(object): ... def __hash__(self): return id(self) ... >>> hash (X()) Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-08 01:03 Message: Logged In: YES user_id=1038590 MvL diagnosed the problem on python-dev as being due to id(obj) now always returning positive values (which may sometimes be a long). This seems like sufficient justification to change the hashing implementation to tolerate long values being returned from __hash__ methods (e.g. by using the hash of a returned long value, instead of trying to convert it to a C int directly). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536021&group_id=5470 From noreply at sourceforge.net Mon Aug 7 17:08:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Aug 2006 08:08:24 -0700 Subject: [ python-Bugs-1536059 ] Missing builtin help for with and as Message-ID: Bugs item #1536059, was opened at 2006-08-08 01: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=1536059&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Missing builtin help for with and as Initial Comment: The builtin help system has no results for help('with') and help('as'). This needs to be fixed for 2.6 when the with statement is available by default. The two new keywords will also need to be listed under help('keywords'). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536059&group_id=5470 From noreply at sourceforge.net Mon Aug 7 19:51:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Aug 2006 10:51:53 -0700 Subject: [ python-Bugs-1112549 ] cgi.FieldStorage memory usage can spike in line-oriented ops Message-ID: Bugs item #1112549, was opened at 2005-01-30 08:40 Message generated for change (Comment added) made by chrism You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 Please note that this 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: 8 Submitted By: Chris McDonough (chrism) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.FieldStorage memory usage can spike in line-oriented ops Initial Comment: Various parts of cgi.FieldStorage call its "read_lines_to_outerboundary", "read_lines" and "skip_lines" methods. These methods use the "readline" method of the file object that represents an input stream. The input stream is typically data supplied by an untrusted source (such as a user uploading a file from a web browser). The input data is not required by the RFC 822/1521/1522/1867 specifications to contain any newline characters. For example, it is within the bounds of the specification to supply a a multipart/form-data input stream with a "file-data" part that consists of a 2GB string composed entirely of "x" characters (which happens to be something I did that led me to noticing this bug). The simplest fix is to make use of the "size" argument of the readline method of the file object where it is used within all parts of FieldStorage that make use of it. A patch against the Python 2.3.4 cgi.py module that does this is attached. ---------------------------------------------------------------------- >Comment By: Chris McDonough (chrism) Date: 2006-08-07 13:51 Message: Logged In: YES user_id=32974 Yup, test/output/test_cgi did need fixing. Apologies, I did not understand the test regime. A new patch file named test_output_test_cgi- svn-50879.patch has been uploaded with the required change. regrtest.py now passes. As far as verify vs. vereq, the test_cgi module uses verify all over the place. I'm apt to not change all of those places, so to change it in just that one place is probably ineffective. Same for type comparison vs. isinstance. I'm trying to make the smallest change possible as opposed to refactoring the test module. I've uploaded a patch which contains a) the fix to cgi.py, b) the fix to test_cgi.py, and the fix to output/test_cgi. The stylistic change wrt to last_line_lfend is fine with me, but I'll leave that jugment to someone else. I'm not sure how to ensure the fix doesn't create other problems other than what has already been done by proving it still passes the tests it was subjected to in the "old" test suite and adds new tests that prove it no longer has the denial of service problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-07 01:50 Message: Logged In: YES user_id=33168 Doesn't this require a change to test/output/test_cgi or something like that? Does this test pass when run under regrtest.py ? The verify(x == y) should be vereq(x, y). type(a) != type(0), should be not isinstance(a, int). The last chunk of the patch in cgi.py should be: last_line_lfend = line.endswith('\n') rather than the 4 lines of if/else. I don't know if this patch really addresses the problem or creates other problems. However, if someone more knowledgable is confident about this patch, I'm fine with this going in. At this point, it might be better to wait for 2.5.1 though. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-07-27 17:42 Message: Logged In: YES user_id=32974 The files I've just uploaded are revisions to the cgi and test_cgi modules for the current state of the SVN trunk. If someone could apply these, it would be appreciated, or give me access and I'll be happy to. FTR, this is a bug which exposes systems which use the cgi.FieldStorage class (most Python web frameworks do) to a denial of service potential. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-02 23:00 Message: Logged In: YES user_id=32974 FYI, I'd be happy to do the merging here if you wanted to give me checkin access. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-02 22:42 Message: Logged In: YES user_id=32974 An updated test_cgi.py is attached. I test both the readline behavior and add a test for basic multipart parsing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 23:48 Message: Logged In: YES user_id=6380 Can I tweak you into uploading a unit test? ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-03-31 21:56 Message: Logged In: YES user_id=32974 Re: parse_multipart.. yes, it looks like there's no use fixing that as it just turns around and puts the line into a list.. it is vulnerable but just by virtue of its non-use of a tempfile, it appears doomed anyway for large requests. I don't know of anything that uses it. Good catch wrt boundary recognition bug, I'm uploading another patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 17:13 Message: Logged In: YES user_id=6380 Methinks that the fix isn't quite right: it would incorrectly recognize as a boundary a very long line starting with "--" followed by the appropriate random string at offset 2**16. This could probably be taken care of by adding a flag that is true initially and after that keeps track of whether the previous line ended in \n. Also, there's a call to fp.readline() in parse_multipart() that you didn't patch -- it wouldn't help because that code is saving the lines in a list anyway, but isn't that code vulnerable as well? Or is it not used? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 From noreply at sourceforge.net Tue Aug 8 00:12:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Aug 2006 15:12:41 -0700 Subject: [ python-Bugs-1536339 ] "make install" doesn't install to /usr/lib64 on x86_64 boxes Message-ID: Bugs item #1536339, was opened at 2006-08-07 22: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=1536339&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Submitted By: Bernhard Rosenkraenzer (bero) Assigned to: Nobody/Anonymous (nobody) Summary: "make install" doesn't install to /usr/lib64 on x86_64 boxes Initial Comment: Most Linux distributions for x86_64 and ia64 place 64bit libraries (including binary python modules) in /usr/lib64 -- the python installation process unconditionally installs to /usr/lib, causing parallel installations of 32bit and 64bit python versions to disturb each other. Last verified in 2.5b3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536339&group_id=5470 From noreply at sourceforge.net Tue Aug 8 02:23:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Aug 2006 17:23:35 -0700 Subject: [ python-Bugs-1486335 ] httplib: read/_read_chunked failes with ValueError sometime Message-ID: Bugs item #1486335, was opened at 2006-05-11 10:14 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486335&group_id=5470 Please note that this 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: kxroberto (kxroberto) Assigned to: Greg Ward (gward) Summary: httplib: read/_read_chunked failes with ValueError sometime Initial Comment: This occasionally shows up in a logged trace, when a application crahes on ValueError on a http(s)_response.read() : (py2.3.5 - yet relevant httplib code is still the same in current httplib) .... \' File "socket.pyo", line 283, in read\\n\', \' File "httplib.pyo", line 389, in read\\n\', \' File "httplib.pyo", line 426, in _read_chunked\\n\', \'ValueError: invalid literal for int(): \\n\'] ::: its the line: chunk_left = int(line, 16) Don't know what this line is about. Yet, that should be protected, as a http_response.read() should not fail with ValueError, but only with IOError/EnvironmentError, socket.error - otherwise Error Exception handling becomes a random task. -Robert Side note regarding IO exception handling: See also FR #1481036 (IOBaseError): why socket.error.__bases__ is (,) ? ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-08-08 01:23 Message: Logged In: YES user_id=261020 I think it's only worth worrying about bad chunking that a) has been observed in the wild (though not necessarily by us) and b) popular browsers can cope with. Greg: """If there is an error here, it's at EOF, so it's not that big a deal.""" That's only if the response will be closed at the end of the current transaction. Quoting from 1411097: """if the connection will not close at the end of the transaction, the behaviour should not change from what's currently in SVN (we should not assume that the chunked response has ended unless we see the proper terminating CRLF).""" Perhaps we don't need to be quite as strict as that, but the point is that otherwise, how do we know the server hasn't already sent that last CRLF, and that it will turn up in three weeks' time?-) If that happens, not sure exactly how httplib will treat the CRLF and possible chunked encoding trailers, but I suspect something bad happens. Perhaps we could just always close the connection in this case? I'm not confident I know yet how best to fix these issues. I just tried reading curl's transfer.c and http_chunks.c. I discovered only that I have to be fully awake to read a 1200 line function :-/ ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2006-07-26 03:13 Message: Logged In: YES user_id=14422 OK, I've been working on this some more and I have a very crude addition to test_httplib.py. I'm going to attach it here and solicit feedback on python-dev: I'm not sure how many kinds of bad response chunking I really want to worry about. ---------------------------------------------------------------------- Comment By: Greg Ward (gward) Date: 2006-07-24 20:38 Message: Logged In: YES user_id=14422 I'm seeing this with Python 2.3.5 and 2.4.3 hitting a PHP app and getting a large error page. It looks as though the server is incorrectly chunking the response: lwp-request at least gives a better error message than httplib.py: $ GET "http://..." 500 EOF when chunk header expected I'm unclear on precisely what the server is doing wrong. The response looks like this: HTTP/1.1 200 OK Date: Mon, 24 Jul 2006 19:18:47 GMT Server: Apache/2.0.54 (Fedora) X-Powered-By: PHP/4.3.11 Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=UTF-8 2169\r\n \r\n [...first 0x2169 bytes of response...]\r\n 20b2\r\n [...next 0x20b2 bytes...] [...repeat many times...] 20b2\r\n [...the last 0x20b2 bytes...] \r\n The blank line at eof appears to be confusing httplib.py: it bombs because int('', 16) raises ValueError. Observation #1: if this is indeed a protocol error (ie. the server is in the wrong), httplib.py should turn the ValueError into an HTTPException. Perhaps it should define a new exception class for low-level protocol errors (bad chunking). Maybe it should reuse IncompleteRead. Observation #2: gee, my web browser doesn't barf on this response, so why should httplib.py? If there is an error here, it's at EOF, so it's not that big a deal. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486335&group_id=5470 From noreply at sourceforge.net Tue Aug 8 02:44:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Aug 2006 17:44:35 -0700 Subject: [ python-Bugs-1339883 ] TAB SETTINGS DONT WORK (win) Message-ID: Bugs item #1339883, was opened at 2005-10-27 15:41 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339883&group_id=5470 Please note that this 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.4 Status: Open >Resolution: Wont Fix Priority: 5 Submitted By: reson5 (reson5) >Assigned to: Kurt B. Kaiser (kbk) Summary: TAB SETTINGS DONT WORK (win) Initial Comment: Hi! I have downloaded newer version of Python and unfortunately the TAB settings in IDLE have no effect on the spaces inserted - ALWAYS 4 spaces. Previous release had the same problem. Win 2k, Python 2.4.2. Regards, Reson ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-07 20:44 Message: Logged In: YES user_id=149084 Yes, as designed. Python strongly encourages the use of four space indent. If you really need to change this for some reason, modify the config-main.def section [Indent] num-spaces value. The colums per tab dialog in tabify/untabify is used for converting tabbed code to spaced code. Weirdly indented code (i.e. 6 spaces) can be converted to tabs and then back to four space indent using those two functions. What is your use case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339883&group_id=5470 From noreply at sourceforge.net Tue Aug 8 04:20:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 7 Aug 2006 19:20:32 -0700 Subject: [ python-Bugs-1520176 ] non-uniform behavior in 'startswith' / 'endswith' Message-ID: <200608080220.k782KWZi006769@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1520176, was opened at 2006-07-10 12:49 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520176&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 >Status: Closed Resolution: None Priority: 5 Submitted By: Milind (t-milich) Assigned to: Raymond Hettinger (rhettinger) Summary: non-uniform behavior in 'startswith' / 'endswith' Initial Comment: compare the two versions of 'endswith'. Either both of them should throw TypeErorr or both should return boolean value. >>> 'abc'.endswith( ('abc',None)) True >>> 'abc'.endswith( ('abc',None),4,3) Traceback (most recent call last): File "", line 1, in TypeError: expected a character buffer object ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2006-08-07 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-10 13:15 Message: Logged In: YES user_id=849994 The current code shortcuts if it finds a match, so I think this is not a bug. Raymond? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1520176&group_id=5470 From noreply at sourceforge.net Tue Aug 8 05:03:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Aug 2006 20:03:51 -0700 Subject: [ python-Bugs-1339883 ] TAB SETTINGS DONT WORK (win) Message-ID: Bugs item #1339883, was opened at 2005-10-27 15:41 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339883&group_id=5470 Please note that this 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.4 Status: Open Resolution: Wont Fix Priority: 5 Submitted By: reson5 (reson5) Assigned to: Kurt B. Kaiser (kbk) Summary: TAB SETTINGS DONT WORK (win) Initial Comment: Hi! I have downloaded newer version of Python and unfortunately the TAB settings in IDLE have no effect on the spaces inserted - ALWAYS 4 spaces. Previous release had the same problem. Win 2k, Python 2.4.2. Regards, Reson ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-07 23:03 Message: Logged In: YES user_id=149084 Yes, as designed. Python strongly encourages the use of four space indent. If you really need to change this for some reason, modify the config-main.def section [Indent] num-spaces value. The colums per tab dialog in tabify/untabify is used for converting tabbed code to spaced code. Weirdly indented code (i.e. 6 spaces) can be converted to tabs and then back to four space indent using those two functions. What is your use case? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-07 20:44 Message: Logged In: YES user_id=149084 Yes, as designed. Python strongly encourages the use of four space indent. If you really need to change this for some reason, modify the config-main.def section [Indent] num-spaces value. The colums per tab dialog in tabify/untabify is used for converting tabbed code to spaced code. Weirdly indented code (i.e. 6 spaces) can be converted to tabs and then back to four space indent using those two functions. What is your use case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339883&group_id=5470 From noreply at sourceforge.net Tue Aug 8 08:02:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 07 Aug 2006 23:02:45 -0700 Subject: [ python-Bugs-1535502 ] Python 2.5 windows builds should link hashlib with OpenSSL Message-ID: Bugs item #1535502, was opened at 2006-08-06 12:38 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535502&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Gregory P. Smith (greg) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5 windows builds should link hashlib with OpenSSL Initial Comment: The Windows builds of Python 2.5 need to be updated to build and link the hashlib modules with OpenSSL 0.9.8. The OpenSSL implementations of the hash algorithms are *much* faster (often 2-3x) than the fallback C implementations that python includes for use when OpenSSL isn't available. I just tested the python 2.5b3 installer on windows. its using the fallback versions rather than OpenSSL: here's a simple way to check from a running python: Without OpenSSL: >>> import hashlib >>> hashlib.sha1 With OpenSSL: >>> import hashlib >>> hashlib.sha1 (please use openssl 0.9.8; older versions don't include sha256 and sha512 implementations) ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-08-07 23:02 Message: Logged In: YES user_id=413 i've attached a patch to PCbuild/build_ssl.py that should build the assembly optimized OpenSSL on windows by default. Still todo: a _hashlib.vcproj file is needed. though wouldn't it be easier for me to just build _hashlib.pyd from within the _ssl.mak file? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535502&group_id=5470 From noreply at sourceforge.net Tue Aug 8 09:48:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Aug 2006 00:48:25 -0700 Subject: [ python-Bugs-1535502 ] Python 2.5 windows builds should link hashlib with OpenSSL Message-ID: Bugs item #1535502, was opened at 2006-08-06 12:38 Message generated for change (Comment added) made by greg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535502&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Gregory P. Smith (greg) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5 windows builds should link hashlib with OpenSSL Initial Comment: The Windows builds of Python 2.5 need to be updated to build and link the hashlib modules with OpenSSL 0.9.8. The OpenSSL implementations of the hash algorithms are *much* faster (often 2-3x) than the fallback C implementations that python includes for use when OpenSSL isn't available. I just tested the python 2.5b3 installer on windows. its using the fallback versions rather than OpenSSL: here's a simple way to check from a running python: Without OpenSSL: >>> import hashlib >>> hashlib.sha1 With OpenSSL: >>> import hashlib >>> hashlib.sha1 (please use openssl 0.9.8; older versions don't include sha256 and sha512 implementations) ---------------------------------------------------------------------- >Comment By: Gregory P. Smith (greg) Date: 2006-08-08 00:48 Message: Logged In: YES user_id=413 attached is a patch that works for me on Win XP with MSVS 2003 (vc++ 7.1): build_hashlib_with_ssl-01.patch It does several things: build_ssl.py -- this is fixed to use do_masm.bat instead of a modified 32all.bat to build OpenSSL with x86 asm optimizations on Win32. It is also fixed to work when under a directory tree with spaces in the directory names. _ssl.mak -- since both _ssl and _hashlib depend on OpenSSL it made the most sense for both to be built by the same makefile. I added _hashlib's build here. _ssl.vcproj -- adds the dependancy on Modules/_hashopenssl.c Things still TODO - make sure _hashlib.pyd is added to the MSI installer. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-08-07 23:02 Message: Logged In: YES user_id=413 i've attached a patch to PCbuild/build_ssl.py that should build the assembly optimized OpenSSL on windows by default. Still todo: a _hashlib.vcproj file is needed. though wouldn't it be easier for me to just build _hashlib.pyd from within the _ssl.mak file? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535502&group_id=5470 From noreply at sourceforge.net Tue Aug 8 11:22:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Aug 2006 02:22:52 -0700 Subject: [ python-Bugs-1333982 ] Bugs of the new AST compiler Message-ID: Bugs item #1333982, was opened at 2005-10-21 10:08 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: AST Status: Closed Resolution: Fixed Priority: 9 Submitted By: Armin Rigo (arigo) Assigned to: Neal Norwitz (nnorwitz) Summary: Bugs of the new AST compiler Initial Comment: The newly merged AST branch is likely to expose a number of small problems before it stabilizes, so here is a tentative bug tracker entry to collect such small problems. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-08-08 09:22 Message: Logged In: YES user_id=4771 Yes, I re-checked and all the bugs listed here are fixed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-04 05:10 Message: Logged In: YES user_id=33168 I believe this addresses all the bugs. If you find new bugs, please open a new report so it's easier to track. Committed revision 51081. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-03 07:26 Message: Logged In: YES user_id=33168 Fix pending. need tests and code to be thawed. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2006-07-09 21:23 Message: Logged In: YES user_id=35752 Unary minus bug has been fixed in SVN rev 50495. ---------------------------------------------------------------------- Comment By: Neil Schemenauer (nascheme) Date: 2006-07-09 21:05 Message: Logged In: YES user_id=35752 Regarding the -2147483648 bug: the old compiler tries to fold unary +, - and ~ if the RHS is a constant. I think only the minus case is important since the others are just optimizations, right? Attaching what seems to be a minimum fix. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-02 11:29 Message: Logged In: YES user_id=4771 Attached a patch for the LOAD_CONST POP_TOP optimization (modified from Georg Brandl on python-dev). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-04-11 09:41 Message: Logged In: YES user_id=6656 Good morning Armin! I've reported that bug already: http://python.org/sf/1441486 There's a patch which purports to fix it: http://python.org/sf/1446922 but I haven't gotten around to testing it. (this is running the pypy/module/array tests or something, isn't it?) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-04-11 08:45 Message: Logged In: YES user_id=4771 Another one: the literal -2147483648 (i.e. the value of -sys.maxint-1) gives a long in 2.5, but an int in <= 2.4. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-04-03 07:30 Message: Logged In: YES user_id=33168 The tuple store problem is fixed. The only outstanding item is the LOAD_CONST/POP_TOP. I will fix that soon. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-02-18 06:56 Message: Logged In: YES user_id=33168 Jeremy, there's no need to read anything before my last comment at 2005-12-17 23:10. The last two by Armin, Michael, then my last comment are the only important ones. Everything that occurred before my 2005-12-17 comment was taken care of AFAIK. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-02-12 21:54 Message: Logged In: YES user_id=4771 Subscripting is generally a bit sloppy: e.g. the AST model has no way to distinguish between a single value and a one-element tuple value! See: >>> d = {} >>> d[1,] = 6 >>> d {1: 6} # ! I suggest we fix the model to turn the 'subs' of the 'Subscript' node from a list of nodes to a single, mandatory 'sub' node. If tupling is necessary, it can be explicitly represented with a 'sub' containing a 'Tuple' node. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-02-09 15:02 Message: Logged In: YES user_id=6656 We found another one. Something is wrong in the compilation of augmented assignment to subscriptions containing tuples; running this code: class C: def __setitem__(self, i, v): print i, v def __getitem__(self, i): print i return 0 c = C() c[4,5] += 1 gives a spurious exception: Traceback (most recent call last): File "", line 1, in TypeError: object does not support item assignment By contrast, "c[(4,5)] += 1" works fine. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-12-18 07:10 Message: Logged In: YES user_id=33168 EXTENDED_ARG problem was fixed a while ago. The assert/pass problem was fixed with: 41756. That leaves the LOAD_CONST/POP_TOP optimization that was lost and one compiler warning: marshal_write_mod() not being used. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-12-11 00:41 Message: Logged In: YES user_id=6656 You have to include those lines in a source file. It still crashes for me. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2005-12-10 23:44 Message: Logged In: YES user_id=357491 I just checked Armin's problem code on rev. 41638 and it worked for me in the interpreter. You still having problems, Armin? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-12-04 10:30 Message: Logged In: YES user_id=4771 At rev 41584, the following code snippet triggers an assert if --with-pydebug is enabled: Python/compile.c:3843: assemble_lnotab: Assertion 'd_lineno >= 0' failed ----------------------- assert 1, ([s for s in x] + [s for s in x]) pass ----------------------- ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-23 19:14 Message: Logged In: YES user_id=33168 Checkpoint of outstanding issues. I think all the others mentioned so far have been fixed: * Raymond's warnings in compile.c (unused locals are fixed) * EXTENDED_ARG problem * LOAD_CONST/POP_TOP (note we can fix this in the optimizer generally which would get rid of other useless code too) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-10-23 04:53 Message: Logged In: YES user_id=80475 FWIW, here are the warnings issued by my compiler: Python-ast.c C:\py25\Python\Python-ast.c(1995) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2070) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2085) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2130) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2151) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2261) : warning C4101: 'i' : unreferenced local variable C:\py25\Python\Python-ast.c(2270) : warning C4101: 'i' : unreferenced local variable compile.c C:\py25\Python\compile.c(3782) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3802) : warning C4305: '=' : truncation from 'const int ' to 'char ' C:\py25\Python\compile.c(3806) : warning C4305: '=' : truncation from 'const int ' to 'char ' ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-22 07:28 Message: Logged In: YES user_id=33168 I assigned to Jeremy and Neil in the hopes they will see this message and know about these problems. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 12:45 Message: Logged In: YES user_id=4771 The following (similarly strange-looking) code snippets compiled successfully before, now they give SyntaxErrors: -------------------- def f(): class g: exec "hi" x -------------------- def f(x): class g: exec "hi" x -------------------- def f(): class g: from a import * x -------------------- def f(x): class g: from a import * x ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 12:33 Message: Logged In: YES user_id=4771 I would suspect the following one to be due to incorrect handling of EXTENDED_ARG -- it's from a PyPy test about that: longexpr = 'x = x or ' + '-x' * 2500 code = ''' def f(x): %s %s %s %s %s %s %s %s %s %s while x: x -= 1 # EXTENDED_ARG/JUMP_ABSOLUTE here return x ''' % ((longexpr,)*10) exec code f(5) SystemError: unknown opcode dis.dis() shows that the target of both the SETUP_LOOP and the JUMP_IF_FALSE at the start of the loop are wrong. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 12:15 Message: Logged In: YES user_id=4771 The Python rules about which names get mangled are a bit insane. I share mwh's view that mangling should never have been invented in the first place, but well: >>> def f(): ... __x = 5 ... class X: ... def g(self): ... return __x ... return X ... Fatal Python error: unknown scope for _X__x in X(135832776) in ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 12:01 Message: Logged In: YES user_id=4771 For reference, an optimization that got lost: def f(): 'a' 'b' 'a' is the docstring, but the 'b' previously did not show up anywhere in the code object. Now there is the LOAD_CONST/POP_TOP pair. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 11:54 Message: Logged In: YES user_id=4771 any reason why lambda functions have a __name__ of 'lambda' now instead of '' ? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 10:22 Message: Logged In: YES user_id=4771 import a as b, c the 'c' part gets completely forgotten and there is no 'IMPORT_NAME c' in the bytecode. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-10-21 10:13 Message: Logged In: YES user_id=4771 A scoping problem (comparing with the old compiler): class X: print hello The variable 'hello' is incorrectly looked up with LOAD_GLOBAL instead of LOAD_NAME. It causes a crash in PyPy in a case where the name 'hello' is stored into the class implicitely (via locals()). It can probably be discussed if the bug is in PyPy, but it is a difference in behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&group_id=5470 From noreply at sourceforge.net Tue Aug 8 11:24:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Aug 2006 02:24:30 -0700 Subject: [ python-Bugs-1526585 ] Concatenation on a long string breaks Message-ID: Bugs item #1526585, was opened at 2006-07-21 17:18 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Jp Calderone (kuran) Assigned to: Armin Rigo (arigo) Summary: Concatenation on a long string breaks Initial Comment: Consider this transcript: exarkun at charm:~/Projects/python/trunk$ ./python Python 2.5b2 (trunk:50698, Jul 18 2006, 10:08:36) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> x = 'x' * (2 ** 31 - 1) >>> x = x + 'x' Traceback (most recent call last): File "", line 1, in SystemError: Objects/stringobject.c:4103: bad argument to internal function >>> len(x) Traceback (most recent call last): File "", line 1, in NameError: name 'x' is not defined >>> I would expect some exception other than SystemError and for the locals namespace to not become corrupted. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-08-08 09:24 Message: Logged In: YES user_id=4771 I was away. I will try to get around to it before release candidate one. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-04 05:27 Message: Logged In: YES user_id=33168 Armin, yes that sounds reasonable. Please checkin as soon as possible now that the trunk is not frozen. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-27 08:48 Message: Logged In: YES user_id=4771 Almost missed kuran's note. Kuran: I suppose you meant to use 2**31 instead of 2**32, but you've found another important bug: >>> s = 'x' * (2**32-2) >>> N = len(s) >>> N 2147483647 >>> 2**32 4294967296L Argh! Another check is missing somewhere. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-27 08:38 Message: Logged In: YES user_id=4771 We could reuse the --memlimit option of regrtest in the following way: At the moment it makes no sense to specify a --memlimit larger than Py_ssize_t, like 3GB on 32-bit systems. At least test_bigmem fails completely in this case. From this it seems that the --memlimit actually tells, more precisely, how much of its *address space* the Python test process is allowed to consume. So the value should be clamped to a maximum of MAX(Py_ssize_t). This would solve the current test_bigmem issue. If we do so, then the condition "--memlimit >= MAX(Py_ssize_t)" is precisely what should be checked to know if we can run the test for the bug in the present tracker, and other tests of the same kind, which check what occurs when the *address space* is exhausted. In this way, specifying --memlimit=3G would enable either test_bigmem (on 64-bit systems) or some new test_filladdressspace (on 32-bit systems), as appropriate. Sounds reasonable? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-26 15:50 Message: Logged In: YES user_id=33168 You're correct that bigmem is primarily for testing int/Py_ssize_t. But it doesn't have to be. It has support for machines with largish amounts of memory (and limiting test runs). I didn't know where else to put such a test. I agree that this bug would only occur on 32-bit platforms. Most machines can't run it, so about the only other option I can think of would be to put it in it's own file and add a -u option. That seemed like even more work. I'm not tied to bigmem at all, but it would be nice to have a test for this somewhere. I'm sure there are a bunch of other places we have this sort of overflow and it would be good to test them somewhere. Do whatever you think is best. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-26 09:01 Message: Logged In: YES user_id=4771 I'm unsure about how the bigmem tests should be used. I think that I am not supposed to set a >2G limit on a 32-bit machine, right? When I do, I get 9 failures: 8 OverflowErrors and a stranger AssertionError in test_hash. I think that these tests are meant to test the int/Py_ssize_t difference on 64-bit machines instead. The bug this tracker is about only shows up on 32-bit machines. My concern is that if we add a test for the current bug in test_bigmem, then with a memory limit < 2GB the test is essentially skipped, and with a memory limit > 2GB then 9 other tests fail anyway. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-26 04:19 Message: Logged In: YES user_id=33168 Armin, can you check in your patch and backport? Also a news entry and a test in test_bigmem would be great. Thanks. If not let me know (assign to me) and I'll finish this up. This fix should be backported as well. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-07-25 20:06 Message: Logged In: YES user_id=366566 Tested Armin's patch, looks like it addresses the issue. One thing I noticed though, ('x' * (2 ** 32 - 2) + 'x') fails the same way ('x' * (2 ** 32 - 1) + 'x'). Don't really understand why, just thought I'd mention it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-25 18:25 Message: Logged In: YES user_id=4771 The check should be done before the variable is removed from the namespace, so that 'x' doesn't just disappear. Attached a patch that does this. Also, let's produce an exception consistent with what PyString_Concat() raises in the same case, which is an OverflowError instead of a MemoryError. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-25 03:57 Message: Logged In: YES user_id=31435 [Neal] > Tim since we know both lens are >= 0, is this test > sufficient for verifying overflow: > > Py_ssize_t new_len = v_len + w_len; > if (new_len < 0) { Right! That's all the new checking needed in string_concatenate(). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-25 03:46 Message: Logged In: YES user_id=33168 Attached a patch against 2.5. The patch should work against 2.4 too, but you will need to change all Py_ssize_t to int. Tim since we know both lens are >= 0, is this test sufficient for verifying overflow: Py_ssize_t new_len = v_len + w_len; if (new_len < 0) { Jp, can you test the patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-22 14:11 Message: Logged In: YES user_id=31435 Part of the problem appears to be that ceval.c's string_concatenate() doesn't check for overflow in the second argument here: if (_PyString_Resize(&v, v_len + w_len) != 0) The Windows malloc on my box returns NULL (and so Python raises MemoryError) on the initial: x = 'x' * (2 ** 31 - 1) attempt, so I never get that far. I'm afraid this is muddier in strange ways on Linux because the Linux malloc() is pathologically optimistic (can return a non-NULL value pointing at "memory" that can't actually be used for anything). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-07-22 09:00 Message: Logged In: YES user_id=6656 Confirmed with 2.4. Ouch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470 From noreply at sourceforge.net Tue Aug 8 12:25:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Aug 2006 03:25:26 -0700 Subject: [ python-Bugs-1536021 ] hash(method) sometimes raises OverflowError Message-ID: Bugs item #1536021, was opened at 2006-08-07 14:21 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536021&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Christian Tanzer (tanzer) Assigned to: Nobody/Anonymous (nobody) Summary: hash(method) sometimes raises OverflowError Initial Comment: I've run into a problem with a big application that I wasn't able to reproduce with a small example. The code (exception handler added to demonstrate and work around the problem): try : h = hash(p) except OverflowError, e: print type(p), p, id(p), e h = id(p) & 0x0FFFFFFF prints the following output: > 3066797028 long int too large to convert to int This happens with Python 2.5b3, but didn't happen with Python 2.4.3. I assume that the hash-function for function/methods returns the `id` of the function. The following code demonstrates the same problem with a Python class whose `__hash__` returns the `id` of the object: $ python2.4 Python 2.4.3 (#1, Jun 30 2006, 10:02:59) [GCC 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X(object): ... def __hash__(self): return id(self) ... >>> hash (X()) -1211078036 $ python2.5 Python 2.5b3 (r25b3:51041, Aug 7 2006, 15:35:35) [GCC 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X(object): ... def __hash__(self): return id(self) ... >>> hash (X()) Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-08-08 10:25 Message: Logged In: YES user_id=4771 The hash of instance methods changed, and id() changed to return non-negative numbers (so that id() is not the default hash any more). But I cannot see how your problem shows up. The only thing I could imagine is that the Script_Category class has a custom __hash__() method which returns a value that is sometimes a long, as it would be if it were based on id(). (It has always been documented that just returning id() in custom __hash__() methods doesn't work because of this, but on 32-bit machines the problem only became apparent with the change in id() in Python 2.5.) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-07 15:03 Message: Logged In: YES user_id=1038590 MvL diagnosed the problem on python-dev as being due to id(obj) now always returning positive values (which may sometimes be a long). This seems like sufficient justification to change the hashing implementation to tolerate long values being returned from __hash__ methods (e.g. by using the hash of a returned long value, instead of trying to convert it to a C int directly). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536021&group_id=5470 From noreply at sourceforge.net Tue Aug 8 14:15:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Aug 2006 05:15:28 -0700 Subject: [ python-Bugs-1019808 ] wrong socket error returned Message-ID: Bugs item #1019808, was opened at 2004-08-31 12:18 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Submitted By: Federico Schwindt (fgsch) Assigned to: A.M. Kuchling (akuchling) Summary: wrong socket error returned Initial Comment: hi, first, background: OS: OpenBSD-current/i386 Python version: 2.3.4 example script: import socket socket.setdefaulttimeout(30) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(('127.0.0.1', 9999)) where nothing is listening on 9999 (ECONNREFUSED should be returned). when ran it i get: Traceback (most recent call last): File "bug.py", line 8, in ? s.connect(('127.0.0.1', 9999)) File "", line 1, in connect socket.error: (22, 'Invalid argument') this is a problem in the socketmodule.c, in the internal_connect() function. getsockopt with SOCK_ERROR should be used once EINPROGRESS is returned to get the real error. this code works on linux, but the connect semantic is, imho, broken. you cannot reuse a socket once it failed (a test afterwards shown that this is valid under linux!!!!). please contact me if you need further details, although i find this very clear. thanks, f.- ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-08 08:15 Message: Logged In: YES user_id=11375 I agree -- this sort of Unix-platform-specific bugfix is always risky. It would have been better if this patch could have been committed in one of the alphas. I'll put this bug in the Python 2.6 group and commit it after 2.5final is released (perhaps it can also go on the release25-maint branch at that time). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-04 01:34 Message: Logged In: YES user_id=33168 Andrew, I'm ok with this patch, but not enthusiastic for 2.5. It might be better to wait for 2.5.1 in order to give this more time to settle. I agree that this change *should* be correct, but who knows if it will break some other platform(s). I leave it to you whether to apply for 2.5 or 2.5.1. It would be good to actually test this condition too. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:31 Message: Logged In: YES user_id=11375 Deleting broken patches; attaching a correct version against 2.5 trunk. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:18 Message: Logged In: YES user_id=11375 I can confirm the bug on MacOS X, and the failure of the patch to fix it. I think the logic of the patch is wrong; it saves errno in save_errno when errno==EINPROGRESS, does a getsockopt(), and then resets errno to save_errno, which we know is EINPROGRESS. I think the correct action is to do 'errno = ". Revised patch attached; it produces the correct result on OS X. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:15 Message: Logged In: YES user_id=11375 I can confirm the bug on MacOS X, and the failure of the patch to fix it. I think the logic of the patch is wrong; it saves errno in save_errno when errno==EINPROGRESS, does a getsockopt(), and then resets errno to save_errno, which we know is EINPROGRESS. I think the correct action is to do 'errno = ". Revised patch attached; it produces the correct result on OS X. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-08-03 10:14 Message: Logged In: YES user_id=11375 I can confirm the bug on MacOS X, and the failure of the patch to fix it. I think the logic of the patch is wrong; it saves errno in save_errno when errno==EINPROGRESS, does a getsockopt(), and then resets errno to save_errno, which we know is EINPROGRESS. I think the correct action is to do 'errno = ". Revised patch attached; it produces the correct result on OS X. ---------------------------------------------------------------------- Comment By: Frank Vercruesse (vercruesse) Date: 2006-02-17 15:46 Message: Logged In: YES user_id=202246 I can confirm the bug running Python 2.4.2 on Mac OS X 10.4.5 (PPC). However, the patch doesn't seem to resolve the issue. Now I get the following traceback when running the posted script: Traceback (most recent call last): File "", line 1, in ? File "", line 1, in connect socket.error: (36, 'Operation now in progress') ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2005-10-03 15:44 Message: Logged In: YES user_id=50493 patch against 2.4.1 appended. not tested in anything but openbsd. nevertheless, i think it should work in linux and osx. not sure about others. cheers. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 02:02 Message: Logged In: YES user_id=33168 Can you provide a patch that you believe corrects this problem? ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2005-06-24 05:41 Message: Logged In: YES user_id=50493 just tried this with 2.4.1 running in OpenBSD 3.7/amd64 and the problem is still there :-( ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2004-09-22 23:58 Message: Logged In: YES user_id=50493 any news? this may be a problem in other *BSDs as well.. ---------------------------------------------------------------------- Comment By: Federico Schwindt (fgsch) Date: 2004-08-31 12:22 Message: Logged In: YES user_id=50493 maybe i was not clear. the problem is only happening when setdefaulttimeout is used. otherwise ECONNREFUSED is correctly returned. f.- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1019808&group_id=5470 From noreply at sourceforge.net Tue Aug 8 15:04:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Aug 2006 06:04:30 -0700 Subject: [ python-Bugs-1536660 ] Micro fix for Reference Manual Message-ID: Bugs item #1536660, was opened at 2006-08-08 10:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536660&group_id=5470 Please note that this 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: Marcelo de Gomensoro Malheiros (mgmalheiros) Assigned to: Nobody/Anonymous (nobody) Summary: Micro fix for Reference Manual Initial Comment: There should be a space in section 2.1.2 (Physical Lines) of the Reference Manual (release 2.4.3): "Unixform" should be "Unix form". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536660&group_id=5470 From noreply at sourceforge.net Tue Aug 8 17:50:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Aug 2006 08:50:52 -0700 Subject: [ python-Bugs-1536786 ] buffer comparison emits a RuntimeWarning Message-ID: Bugs item #1536786, was opened at 2006-08-08 17:50 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536786&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: buffer comparison emits a RuntimeWarning Initial Comment: On some systems, the memcmp() function returns values other than -1, 0, or +1, which gives a warning: >>> cmp(buffer("abc"), buffer("def")) __main__:1: RuntimeWarning: tp_compare didn't return -1, 0 or 1 -1 >>> The problem occurred on OS X and Windows CE. Patch and test attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536786&group_id=5470 From noreply at sourceforge.net Tue Aug 8 18:48:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Aug 2006 09:48:16 -0700 Subject: [ python-Bugs-1536825 ] distutils.sysconfig.get_config_h_filename gets useless file Message-ID: Bugs item #1536825, was opened at 2006-08-08 11:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536825&group_id=5470 Please note that this 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: Parzival Herzog (walt-kelly) Assigned to: Nobody/Anonymous (nobody) Summary: distutils.sysconfig.get_config_h_filename gets useless file Initial Comment: python -v: Python 2.4.1 (#2, Aug 25 2005, 18:20:57) [GCC 4.0.1 (4.0.1-2mdk for Mandriva Linux release 2006.0)] on linux2 While attempting to install cElementTree, the setup build failed because the setup.py attempted to parse the sysconfig.h file, using the filename provided by distutils.sysconfig.get_config_h_filename(). The file retrieved was "/usr/include/python2.4/pyconfig.h", which contains the text: ---------- #define _MULTIARCH_HEADER python2.4/pyconfig.h #include ---------- The cElementTree setup.py script then parsed this file, and attempted to configure itself as follows: -------- # determine suitable defines (based on Python's setup.py file) config_h = sysconfig.get_config_h_filename() config_h_vars = sysconfig.parse_config_h(open(config_h)) for feature_macro in ["HAVE_MEMMOVE", "HAVE_BCOPY"]: if config_h_vars.has_key(feature_macro): defines.append((feature_macro, "1")) -------- Since file with useful information is in "/usr/include/multiarch-i386-linux/python2.4/pyconfig.h", the subsequent build failed due to no HAVE_MEMMOVE or HAVE_BCOPY macro being defined. So, either 1) the cElementTree setup.py script is too clever for its own good, or is not clever enough, (tell that to F. Lundh) or 2) the sysconfig.get_config_h_filename is returning the wrong filename (i.e. a file that does not actually contain the needed configuration information), or 3) sysconfig.parse_config_h should, but does not follow the multi-arch-dispatch.h include, to get at the real sysconfig_h defines, or 4) Mandriva 2006 has messed up the Python distribution with that multi-arch-dispatch thing. I'm hoping that a solution is found rectifying either (2) or (3). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536825&group_id=5470 From noreply at sourceforge.net Tue Aug 8 18:52:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Aug 2006 09:52:15 -0700 Subject: [ python-Bugs-1536786 ] buffer comparison emits a RuntimeWarning Message-ID: Bugs item #1536786, was opened at 2006-08-08 11: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=1536786&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open >Resolution: Accepted Priority: 5 Submitted By: Thomas Heller (theller) >Assigned to: Thomas Heller (theller) Summary: buffer comparison emits a RuntimeWarning Initial Comment: On some systems, the memcmp() function returns values other than -1, 0, or +1, which gives a warning: >>> cmp(buffer("abc"), buffer("def")) __main__:1: RuntimeWarning: tp_compare didn't return -1, 0 or 1 -1 >>> The problem occurred on OS X and Windows CE. Patch and test attached. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-08-08 12:52 Message: Logged In: YES user_id=31435 Looks good to me, although I'd collapse the new code to just: if (cmp != 0) return cmp < 0 ? -1 : 1; Marked Accepted and assigned back to you for checkin (or if you can't, assign back to me). Proabably affects 2.4 too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536786&group_id=5470 From noreply at sourceforge.net Tue Aug 8 18:53:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Aug 2006 09:53:30 -0700 Subject: [ python-Bugs-1536828 ] Typo, types.TypeType should read types.StringType Message-ID: Bugs item #1536828, was opened at 2006-08-08 11: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=1536828&group_id=5470 Please note that this 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: Reillyeon (reillyeon) Assigned to: Nobody/Anonymous (nobody) Summary: Typo, types.TypeType should read types.StringType Initial Comment: In Docs/concrete.tex: \begin{cvardesc}{PyTypeObject}{PyString_Type} This instance of \ctype{PyTypeObject} represents the Python string type; it is the same object as \code{types.TypeType} in the Python layer. \withsubitem{(in module types)}{\ttindex{StringType}}. \end{cvardesc} On the third line types.TypeType should instead read types.StringType: \begin{cvardesc}{PyTypeObject}{PyString_Type} This instance of \ctype{PyTypeObject} represents the Python string type; it is the same object as \code{types.StringType} in the Python layer. \withsubitem{(in module types)}{\ttindex{StringType}}. \end{cvardesc} ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536828&group_id=5470 From noreply at sourceforge.net Tue Aug 8 19:45:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Aug 2006 10:45:18 -0700 Subject: [ python-Bugs-1536786 ] buffer comparison emits a RuntimeWarning Message-ID: Bugs item #1536786, was opened at 2006-08-08 17:50 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536786&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Thomas Heller (theller) Summary: buffer comparison emits a RuntimeWarning Initial Comment: On some systems, the memcmp() function returns values other than -1, 0, or +1, which gives a warning: >>> cmp(buffer("abc"), buffer("def")) __main__:1: RuntimeWarning: tp_compare didn't return -1, 0 or 1 -1 >>> The problem occurred on OS X and Windows CE. Patch and test attached. ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-08-08 19:45 Message: Logged In: YES user_id=11105 Thanks. Committed, with the suggested changes, as r51139/51140 on the trunk, and r51141 on the release-24maint branch. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-08-08 18:52 Message: Logged In: YES user_id=31435 Looks good to me, although I'd collapse the new code to just: if (cmp != 0) return cmp < 0 ? -1 : 1; Marked Accepted and assigned back to you for checkin (or if you can't, assign back to me). Proabably affects 2.4 too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536786&group_id=5470 From noreply at sourceforge.net Tue Aug 8 19:59:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Aug 2006 10:59:19 -0700 Subject: [ python-Bugs-1339883 ] TAB SETTINGS DONT WORK (win) Message-ID: Bugs item #1339883, was opened at 2005-10-27 15:41 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339883&group_id=5470 Please note that this 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.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: reson5 (reson5) Assigned to: Kurt B. Kaiser (kbk) Summary: TAB SETTINGS DONT WORK (win) Initial Comment: Hi! I have downloaded newer version of Python and unfortunately the TAB settings in IDLE have no effect on the spaces inserted - ALWAYS 4 spaces. Previous release had the same problem. Win 2k, Python 2.4.2. Regards, Reson ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-08 13:59 Message: Logged In: YES user_id=149084 Ah, ok, I see what you are talking about. This was fixed in 2.5. Try 2.5b3! See Rev 38319 and 38400 at http://svn.python.org/view/python/trunk/Lib/idlelib/ EditorWindow.py?rev=50833&view=log I'm making another change in this area: if the user selects Toggle Tabs and Cancel, his indentation setting is changed to 8. It should not change unless he actually selects Tab indentation. Change should be in 2.5c1, due out around 18Sep. These changes should not be backported to 2.4 since they are essentially feature changes, not just bugs. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-07 23:03 Message: Logged In: YES user_id=149084 Yes, as designed. Python strongly encourages the use of four space indent. If you really need to change this for some reason, modify the config-main.def section [Indent] num-spaces value. The colums per tab dialog in tabify/untabify is used for converting tabbed code to spaced code. Weirdly indented code (i.e. 6 spaces) can be converted to tabs and then back to four space indent using those two functions. What is your use case? ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-07 20:44 Message: Logged In: YES user_id=149084 Yes, as designed. Python strongly encourages the use of four space indent. If you really need to change this for some reason, modify the config-main.def section [Indent] num-spaces value. The colums per tab dialog in tabify/untabify is used for converting tabbed code to spaced code. Weirdly indented code (i.e. 6 spaces) can be converted to tabs and then back to four space indent using those two functions. What is your use case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1339883&group_id=5470 From noreply at sourceforge.net Tue Aug 8 22:11:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Aug 2006 13:11:58 -0700 Subject: [ python-Bugs-1536828 ] Typo, types.TypeType should read types.StringType Message-ID: Bugs item #1536828, was opened at 2006-08-08 16:53 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536828&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Reillyeon (reillyeon) Assigned to: Nobody/Anonymous (nobody) Summary: Typo, types.TypeType should read types.StringType Initial Comment: In Docs/concrete.tex: \begin{cvardesc}{PyTypeObject}{PyString_Type} This instance of \ctype{PyTypeObject} represents the Python string type; it is the same object as \code{types.TypeType} in the Python layer. \withsubitem{(in module types)}{\ttindex{StringType}}. \end{cvardesc} On the third line types.TypeType should instead read types.StringType: \begin{cvardesc}{PyTypeObject}{PyString_Type} This instance of \ctype{PyTypeObject} represents the Python string type; it is the same object as \code{types.StringType} in the Python layer. \withsubitem{(in module types)}{\ttindex{StringType}}. \end{cvardesc} ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-08 20:11 Message: Logged In: YES user_id=849994 Thanks for the report, fixed in rev. 51151, 51152 (2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536828&group_id=5470 From noreply at sourceforge.net Tue Aug 8 22:13:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Aug 2006 13:13:28 -0700 Subject: [ python-Bugs-1536660 ] Micro fix for Reference Manual Message-ID: Bugs item #1536660, was opened at 2006-08-08 13:04 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536660&group_id=5470 Please note that this 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: Marcelo de Gomensoro Malheiros (mgmalheiros) Assigned to: Nobody/Anonymous (nobody) Summary: Micro fix for Reference Manual Initial Comment: There should be a space in section 2.1.2 (Physical Lines) of the Reference Manual (release 2.4.3): "Unixform" should be "Unix form". ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-08 20:13 Message: Logged In: YES user_id=849994 Thanks for the report, fixed in rev. 51153, 51154 (2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536660&group_id=5470 From noreply at sourceforge.net Wed Aug 9 07:40:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Aug 2006 22:40:16 -0700 Subject: [ python-Bugs-1533105 ] NetBSD build with --with-pydebug causes SIGSEGV Message-ID: Bugs item #1533105, was opened at 2006-08-02 06:00 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533105&group_id=5470 Please note that this 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: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: NetBSD build with --with-pydebug causes SIGSEGV Initial Comment: The testInfiniteRecursion test in Lib/test/test_exceptions.py causes Python to segfault if it has been compiled on NetBSD with --with-pydebug. This is due to the fact that the default stack size on NetBSD is 2MB and Python tries to allocate memory for debugging information on the stack. The documentation (README under 'Setting the optimization/debugging options'?) should be updated to state that if you want to run the test suite with debugging enabled in the interpreter, you are advised to increase the stack size, probably to 4096. This issue is also in release24-maint. Matt ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-08 22:40 Message: Logged In: YES user_id=33168 Matt, can you make a patch? Doc changes are fine to go into 2.5 (and 2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533105&group_id=5470 From noreply at sourceforge.net Wed Aug 9 08:01:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Aug 2006 23:01:47 -0700 Subject: [ python-Bugs-1537167 ] 2nd issue with need for speed patch Message-ID: Bugs item #1537167, was opened at 2006-08-09 07: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=1537167&group_id=5470 Please note that this 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: Robin Bryce (robinbryce2) Assigned to: Nobody/Anonymous (nobody) Summary: 2nd issue with need for speed patch Initial Comment: This is not a duplicate of the "realease manager pronouncement on 302 Fix needed" issue raised on pydev. If a custom importer is present, import.c skips the builtin import machinery if the find_module method of that importer returns None. For python 2.4.3 if find_module returns none the normal builtin machinery gets a lookin. The relevent change was the addition of a continue statement with svn commit r46372 (at around line 1283 of import.c on the trunk). I don't understand, in the face of this change, how pep 302 importers are expected to cascade. returning None from find_module is the way an importer says "no I can't load this module but I cant say for certain this means ImportError" isnt it ? One (unintended?) consequence of this change is the following corner case: As __import__ allows non dotted module names __import__('fakemod.a/b') *will* succede on python 2.4.3 provided b is a directory under the package a that contains an __init__.py. In python 2.5b3 this fails. I've atatched a detailed repro case of this particular corner case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537167&group_id=5470 From noreply at sourceforge.net Wed Aug 9 09:08:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 00:08:56 -0700 Subject: [ python-Bugs-1523610 ] PyArg_ParseTupleAndKeywords potential core dump Message-ID: Bugs item #1523610, was opened at 2006-07-17 02:23 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523610&group_id=5470 Please note that this 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: 8 Submitted By: Eric Huss (ehuss) Assigned to: Nobody/Anonymous (nobody) Summary: PyArg_ParseTupleAndKeywords potential core dump Initial Comment: After getting bit by bug 893549, I was noticing that sometimes I was getting a core dump instead of a TypeError when PyArg_ParseTupleAndKeywords was skipping over a type the "skipitem" code does not understand. There are about 4 problems I will describe (though they are related, so it's probably not worth filing seperate bugs). The problem is that the "levels" variable is passed to the seterror function uninitialized. If levels does not happen to contain any 0 elements, then the iteration code in seterror will go crazy (I will get to this in a moment). In the one place where "skipitem" is called, you will notice it immediately calls seterror() if it returned an error message. However, "levels" is not set by the skipitem function, and thus seterror iterates over an uninitialized value. I suggest setting levels[0] = 0 somewhere in the beginning of the code, since the expectations of setting the "levels" seems awefully delicate. (As a side note, there's no bounds checking on the levels variable, either. It seems unlikely that someone will have 32 levels of nested variables, but I think it points to a general problem with how the variable is passed around.) A second fix is to set levels[0] = 0 if setitem fails before calling seterror(). Now, returning to the "seterror goes crazy" problem I mentioned earlier, the following code in the seterror function: while (levels[i] > 0 && (int)(p-buf) < 220) { should be: while (levels[i] > 0 && (int)(p-buf) > 220) { At least, that's what I'm assuming it is supposed to be. I think it should be clear why this is bad. But wait, there's more! The snprintf in seterror call uses the incorrect size of buf. The following line: PyOS_snprintf(p, sizeof(buf) - (buf - p), should be: PyOS_snprintf(p, sizeof(buf) - (p - buf), My particular platform (FreeBSD) puts a NUL character at the end of the buffer. However, since the size of the buffer is computed incorrectly, this line of code stomps on the stack (overwritting the levels value in my case). Let me know if you have any questions, or want any sample code. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-09 07:08 Message: Logged In: YES user_id=849994 Fixed the "levels overflow" problem by introducing an upper bound on the tuple nesting depth in rev. 51158. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-26 08:04 Message: Logged In: YES user_id=849994 Fixed the "levels[0] = 0" and the "p-buf" issue in rev. 50843. Still waiting for input on python-dev about the levels overflow, though I think it can be ignored. ---------------------------------------------------------------------- Comment By: Eric Huss (ehuss) Date: 2006-07-17 02:28 Message: Logged In: YES user_id=393416 Oops, skip the section about <220 being >220. I've been staring at it too long. The rest of the issues should be valid, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1523610&group_id=5470 From noreply at sourceforge.net Wed Aug 9 09:28:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 00:28:42 -0700 Subject: [ python-Bugs-1537195 ] Missing platform information in subprocess documentation Message-ID: Bugs item #1537195, was opened at 2006-08-09 07:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537195&group_id=5470 Please note that this 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: Aaron Bingham (adbingham) Assigned to: Nobody/Anonymous (nobody) Summary: Missing platform information in subprocess documentation Initial Comment: In the Python 2.4 documentation for the subprocess.Popen class (http://www.python.org/doc/current/lib/node235.html), many of the platform differences are documented clearly. However the preexec_fn and close_fds keyword arguments are not supported on Windows and this is not mentioned anywhere obvious. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537195&group_id=5470 From noreply at sourceforge.net Wed Aug 9 09:32:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 00:32:28 -0700 Subject: [ python-Bugs-1537195 ] Missing platform information in subprocess documentation Message-ID: Bugs item #1537195, was opened at 2006-08-09 07:28 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537195&group_id=5470 Please note that this 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: Aaron Bingham (adbingham) Assigned to: Nobody/Anonymous (nobody) Summary: Missing platform information in subprocess documentation Initial Comment: In the Python 2.4 documentation for the subprocess.Popen class (http://www.python.org/doc/current/lib/node235.html), many of the platform differences are documented clearly. However the preexec_fn and close_fds keyword arguments are not supported on Windows and this is not mentioned anywhere obvious. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-09 07:32 Message: Logged In: YES user_id=849994 This was already fixed in SVN and will be in the next docs release. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537195&group_id=5470 From noreply at sourceforge.net Wed Aug 9 09:58:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 00:58:01 -0700 Subject: [ python-Bugs-1536021 ] hash(method) sometimes raises OverflowError Message-ID: Bugs item #1536021, was opened at 2006-08-07 16:21 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536021&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Christian Tanzer (tanzer) Assigned to: Nobody/Anonymous (nobody) Summary: hash(method) sometimes raises OverflowError Initial Comment: I've run into a problem with a big application that I wasn't able to reproduce with a small example. The code (exception handler added to demonstrate and work around the problem): try : h = hash(p) except OverflowError, e: print type(p), p, id(p), e h = id(p) & 0x0FFFFFFF prints the following output: > 3066797028 long int too large to convert to int This happens with Python 2.5b3, but didn't happen with Python 2.4.3. I assume that the hash-function for function/methods returns the `id` of the function. The following code demonstrates the same problem with a Python class whose `__hash__` returns the `id` of the object: $ python2.4 Python 2.4.3 (#1, Jun 30 2006, 10:02:59) [GCC 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X(object): ... def __hash__(self): return id(self) ... >>> hash (X()) -1211078036 $ python2.5 Python 2.5b3 (r25b3:51041, Aug 7 2006, 15:35:35) [GCC 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X(object): ... def __hash__(self): return id(self) ... >>> hash (X()) Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-09 09:58 Message: Logged In: YES user_id=21627 Thanks for the report. Fixed in r51160 ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-08 12:25 Message: Logged In: YES user_id=4771 The hash of instance methods changed, and id() changed to return non-negative numbers (so that id() is not the default hash any more). But I cannot see how your problem shows up. The only thing I could imagine is that the Script_Category class has a custom __hash__() method which returns a value that is sometimes a long, as it would be if it were based on id(). (It has always been documented that just returning id() in custom __hash__() methods doesn't work because of this, but on 32-bit machines the problem only became apparent with the change in id() in Python 2.5.) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-07 17:03 Message: Logged In: YES user_id=1038590 MvL diagnosed the problem on python-dev as being due to id(obj) now always returning positive values (which may sometimes be a long). This seems like sufficient justification to change the hashing implementation to tolerate long values being returned from __hash__ methods (e.g. by using the hash of a returned long value, instead of trying to convert it to a C int directly). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536021&group_id=5470 From noreply at sourceforge.net Wed Aug 9 11:24:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 02:24:20 -0700 Subject: [ python-Bugs-1536021 ] hash(method) sometimes raises OverflowError Message-ID: Bugs item #1536021, was opened at 2006-08-07 14:21 Message generated for change (Comment added) made by tanzer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536021&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 >Status: Open >Resolution: None Priority: 5 Submitted By: Christian Tanzer (tanzer) Assigned to: Nobody/Anonymous (nobody) Summary: hash(method) sometimes raises OverflowError Initial Comment: I've run into a problem with a big application that I wasn't able to reproduce with a small example. The code (exception handler added to demonstrate and work around the problem): try : h = hash(p) except OverflowError, e: print type(p), p, id(p), e h = id(p) & 0x0FFFFFFF prints the following output: > 3066797028 long int too large to convert to int This happens with Python 2.5b3, but didn't happen with Python 2.4.3. I assume that the hash-function for function/methods returns the `id` of the function. The following code demonstrates the same problem with a Python class whose `__hash__` returns the `id` of the object: $ python2.4 Python 2.4.3 (#1, Jun 30 2006, 10:02:59) [GCC 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X(object): ... def __hash__(self): return id(self) ... >>> hash (X()) -1211078036 $ python2.5 Python 2.5b3 (r25b3:51041, Aug 7 2006, 15:35:35) [GCC 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X(object): ... def __hash__(self): return id(self) ... >>> hash (X()) Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int ---------------------------------------------------------------------- >Comment By: Christian Tanzer (tanzer) Date: 2006-08-09 09:24 Message: Logged In: YES user_id=2402 > The only thing I could imagine is that the Script_Category > class has a custom __hash__() method which returns a value > that is sometimes a long, as it would be if it were > based on id(). That was indeed the problem in my code (returning `id(self)`). > It has always been documented that just returning id() > in custom __hash__() methods doesn't work because of > this AFAIR, it was once documented that the default hash value is the id of an object. And I just found a message by the BFDL himself proclaiming so: http://python.project.cwi.nl/search/hypermail/python-recent/0168.html. OTOH, I don't remember seeing anything about this in AMK's `What's new in Python 2.x` documents (but found an entry in NEWS.txt for some 2.5 alpha). I've now changed all my broken `__hash__` methods (not that many fortunately) but it might be a good idea to document this change in a more visible way. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-09 07:58 Message: Logged In: YES user_id=21627 Thanks for the report. Fixed in r51160 ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-08 10:25 Message: Logged In: YES user_id=4771 The hash of instance methods changed, and id() changed to return non-negative numbers (so that id() is not the default hash any more). But I cannot see how your problem shows up. The only thing I could imagine is that the Script_Category class has a custom __hash__() method which returns a value that is sometimes a long, as it would be if it were based on id(). (It has always been documented that just returning id() in custom __hash__() methods doesn't work because of this, but on 32-bit machines the problem only became apparent with the change in id() in Python 2.5.) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-07 15:03 Message: Logged In: YES user_id=1038590 MvL diagnosed the problem on python-dev as being due to id(obj) now always returning positive values (which may sometimes be a long). This seems like sufficient justification to change the hashing implementation to tolerate long values being returned from __hash__ methods (e.g. by using the hash of a returned long value, instead of trying to convert it to a C int directly). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536021&group_id=5470 From noreply at sourceforge.net Wed Aug 9 11:47:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 02:47:56 -0700 Subject: [ python-Bugs-1536021 ] hash(method) sometimes raises OverflowError Message-ID: Bugs item #1536021, was opened at 2006-08-07 14:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536021&group_id=5470 Please note that this 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: Christian Tanzer (tanzer) >Assigned to: A.M. Kuchling (akuchling) Summary: hash(method) sometimes raises OverflowError Initial Comment: I've run into a problem with a big application that I wasn't able to reproduce with a small example. The code (exception handler added to demonstrate and work around the problem): try : h = hash(p) except OverflowError, e: print type(p), p, id(p), e h = id(p) & 0x0FFFFFFF prints the following output: > 3066797028 long int too large to convert to int This happens with Python 2.5b3, but didn't happen with Python 2.4.3. I assume that the hash-function for function/methods returns the `id` of the function. The following code demonstrates the same problem with a Python class whose `__hash__` returns the `id` of the object: $ python2.4 Python 2.4.3 (#1, Jun 30 2006, 10:02:59) [GCC 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X(object): ... def __hash__(self): return id(self) ... >>> hash (X()) -1211078036 $ python2.5 Python 2.5b3 (r25b3:51041, Aug 7 2006, 15:35:35) [GCC 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X(object): ... def __hash__(self): return id(self) ... >>> hash (X()) Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-09 09:47 Message: Logged In: YES user_id=849994 Andrew, do you want to add a whatsnew entry? ---------------------------------------------------------------------- Comment By: Christian Tanzer (tanzer) Date: 2006-08-09 09:24 Message: Logged In: YES user_id=2402 > The only thing I could imagine is that the Script_Category > class has a custom __hash__() method which returns a value > that is sometimes a long, as it would be if it were > based on id(). That was indeed the problem in my code (returning `id(self)`). > It has always been documented that just returning id() > in custom __hash__() methods doesn't work because of > this AFAIR, it was once documented that the default hash value is the id of an object. And I just found a message by the BFDL himself proclaiming so: http://python.project.cwi.nl/search/hypermail/python-recent/0168.html. OTOH, I don't remember seeing anything about this in AMK's `What's new in Python 2.x` documents (but found an entry in NEWS.txt for some 2.5 alpha). I've now changed all my broken `__hash__` methods (not that many fortunately) but it might be a good idea to document this change in a more visible way. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-09 07:58 Message: Logged In: YES user_id=21627 Thanks for the report. Fixed in r51160 ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-08 10:25 Message: Logged In: YES user_id=4771 The hash of instance methods changed, and id() changed to return non-negative numbers (so that id() is not the default hash any more). But I cannot see how your problem shows up. The only thing I could imagine is that the Script_Category class has a custom __hash__() method which returns a value that is sometimes a long, as it would be if it were based on id(). (It has always been documented that just returning id() in custom __hash__() methods doesn't work because of this, but on 32-bit machines the problem only became apparent with the change in id() in Python 2.5.) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-07 15:03 Message: Logged In: YES user_id=1038590 MvL diagnosed the problem on python-dev as being due to id(obj) now always returning positive values (which may sometimes be a long). This seems like sufficient justification to change the hashing implementation to tolerate long values being returned from __hash__ methods (e.g. by using the hash of a returned long value, instead of trying to convert it to a C int directly). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536021&group_id=5470 From noreply at sourceforge.net Wed Aug 9 12:23:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 03:23:22 -0700 Subject: [ python-Bugs-1533105 ] NetBSD build with --with-pydebug causes SIGSEGV Message-ID: Bugs item #1533105, was opened at 2006-08-02 13:00 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533105&group_id=5470 Please note that this 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: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: NetBSD build with --with-pydebug causes SIGSEGV Initial Comment: The testInfiniteRecursion test in Lib/test/test_exceptions.py causes Python to segfault if it has been compiled on NetBSD with --with-pydebug. This is due to the fact that the default stack size on NetBSD is 2MB and Python tries to allocate memory for debugging information on the stack. The documentation (README under 'Setting the optimization/debugging options'?) should be updated to state that if you want to run the test suite with debugging enabled in the interpreter, you are advised to increase the stack size, probably to 4096. This issue is also in release24-maint. Matt ---------------------------------------------------------------------- >Comment By: Matt Fleming (splitscreen) Date: 2006-08-09 10:23 Message: Logged In: YES user_id=1126061 Patches for trunk and 2.4 attached. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-09 05:40 Message: Logged In: YES user_id=33168 Matt, can you make a patch? Doc changes are fine to go into 2.5 (and 2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533105&group_id=5470 From noreply at sourceforge.net Wed Aug 9 14:27:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 05:27:29 -0700 Subject: [ python-Bugs-1537167 ] 2nd issue with need for speed patch Message-ID: Bugs item #1537167, was opened at 2006-08-09 08:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537167&group_id=5470 Please note that this 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: Robin Bryce (robinbryce2) >Assigned to: Phillip J. Eby (pje) Summary: 2nd issue with need for speed patch Initial Comment: This is not a duplicate of the "realease manager pronouncement on 302 Fix needed" issue raised on pydev. If a custom importer is present, import.c skips the builtin import machinery if the find_module method of that importer returns None. For python 2.4.3 if find_module returns none the normal builtin machinery gets a lookin. The relevent change was the addition of a continue statement with svn commit r46372 (at around line 1283 of import.c on the trunk). I don't understand, in the face of this change, how pep 302 importers are expected to cascade. returning None from find_module is the way an importer says "no I can't load this module but I cant say for certain this means ImportError" isnt it ? One (unintended?) consequence of this change is the following corner case: As __import__ allows non dotted module names __import__('fakemod.a/b') *will* succede on python 2.4.3 provided b is a directory under the package a that contains an __init__.py. In python 2.5b3 this fails. I've atatched a detailed repro case of this particular corner case. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-09 14:27 Message: Logged In: YES user_id=21627 I'd say it is a bug that Python 2.4 allows non-dotted module names for __import__. Can you come up with a change in behaviour for "regular" module names? As for cascading: path importers doe not cascade. Per sys.path item, there can be at most one path importer. They "cascade" in the sense that search continues with other sys.path items if it wasn't found in one sys.path entry. This cascading continues to work with 2.5. Phillip, can you take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537167&group_id=5470 From noreply at sourceforge.net Wed Aug 9 15:20:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 06:20:57 -0700 Subject: [ python-Bugs-1536021 ] hash(method) sometimes raises OverflowError Message-ID: Bugs item #1536021, was opened at 2006-08-07 10:21 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536021&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Christian Tanzer (tanzer) Assigned to: A.M. Kuchling (akuchling) Summary: hash(method) sometimes raises OverflowError Initial Comment: I've run into a problem with a big application that I wasn't able to reproduce with a small example. The code (exception handler added to demonstrate and work around the problem): try : h = hash(p) except OverflowError, e: print type(p), p, id(p), e h = id(p) & 0x0FFFFFFF prints the following output: > 3066797028 long int too large to convert to int This happens with Python 2.5b3, but didn't happen with Python 2.4.3. I assume that the hash-function for function/methods returns the `id` of the function. The following code demonstrates the same problem with a Python class whose `__hash__` returns the `id` of the object: $ python2.4 Python 2.4.3 (#1, Jun 30 2006, 10:02:59) [GCC 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X(object): ... def __hash__(self): return id(self) ... >>> hash (X()) -1211078036 $ python2.5 Python 2.5b3 (r25b3:51041, Aug 7 2006, 15:35:35) [GCC 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X(object): ... def __hash__(self): return id(self) ... >>> hash (X()) Traceback (most recent call last): File "", line 1, in OverflowError: long int too large to convert to int ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-08-09 09:20 Message: Logged In: YES user_id=11375 Added. Closing this bug. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-09 05:47 Message: Logged In: YES user_id=849994 Andrew, do you want to add a whatsnew entry? ---------------------------------------------------------------------- Comment By: Christian Tanzer (tanzer) Date: 2006-08-09 05:24 Message: Logged In: YES user_id=2402 > The only thing I could imagine is that the Script_Category > class has a custom __hash__() method which returns a value > that is sometimes a long, as it would be if it were > based on id(). That was indeed the problem in my code (returning `id(self)`). > It has always been documented that just returning id() > in custom __hash__() methods doesn't work because of > this AFAIR, it was once documented that the default hash value is the id of an object. And I just found a message by the BFDL himself proclaiming so: http://python.project.cwi.nl/search/hypermail/python-recent/0168.html. OTOH, I don't remember seeing anything about this in AMK's `What's new in Python 2.x` documents (but found an entry in NEWS.txt for some 2.5 alpha). I've now changed all my broken `__hash__` methods (not that many fortunately) but it might be a good idea to document this change in a more visible way. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-09 03:58 Message: Logged In: YES user_id=21627 Thanks for the report. Fixed in r51160 ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-08 06:25 Message: Logged In: YES user_id=4771 The hash of instance methods changed, and id() changed to return non-negative numbers (so that id() is not the default hash any more). But I cannot see how your problem shows up. The only thing I could imagine is that the Script_Category class has a custom __hash__() method which returns a value that is sometimes a long, as it would be if it were based on id(). (It has always been documented that just returning id() in custom __hash__() methods doesn't work because of this, but on 32-bit machines the problem only became apparent with the change in id() in Python 2.5.) ---------------------------------------------------------------------- Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-07 11:03 Message: Logged In: YES user_id=1038590 MvL diagnosed the problem on python-dev as being due to id(obj) now always returning positive values (which may sometimes be a long). This seems like sufficient justification to change the hashing implementation to tolerate long values being returned from __hash__ methods (e.g. by using the hash of a returned long value, instead of trying to convert it to a C int directly). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536021&group_id=5470 From noreply at sourceforge.net Wed Aug 9 15:28:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 06:28:24 -0700 Subject: [ python-Bugs-1537167 ] 2nd issue with need for speed patch Message-ID: Bugs item #1537167, was opened at 2006-08-09 06:01 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537167&group_id=5470 Please note that this 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: Robin Bryce (robinbryce2) Assigned to: Phillip J. Eby (pje) Summary: 2nd issue with need for speed patch Initial Comment: This is not a duplicate of the "realease manager pronouncement on 302 Fix needed" issue raised on pydev. If a custom importer is present, import.c skips the builtin import machinery if the find_module method of that importer returns None. For python 2.4.3 if find_module returns none the normal builtin machinery gets a lookin. The relevent change was the addition of a continue statement with svn commit r46372 (at around line 1283 of import.c on the trunk). I don't understand, in the face of this change, how pep 302 importers are expected to cascade. returning None from find_module is the way an importer says "no I can't load this module but I cant say for certain this means ImportError" isnt it ? One (unintended?) consequence of this change is the following corner case: As __import__ allows non dotted module names __import__('fakemod.a/b') *will* succede on python 2.4.3 provided b is a directory under the package a that contains an __init__.py. In python 2.5b3 this fails. I've atatched a detailed repro case of this particular corner case. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-09 13:28 Message: Logged In: YES user_id=849994 Guido agreed that the 2.4 behavior is to be regarded as a bug: http://mail.python.org/pipermail/python-dev/2006-May/065174.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-09 12:27 Message: Logged In: YES user_id=21627 I'd say it is a bug that Python 2.4 allows non-dotted module names for __import__. Can you come up with a change in behaviour for "regular" module names? As for cascading: path importers doe not cascade. Per sys.path item, there can be at most one path importer. They "cascade" in the sense that search continues with other sys.path items if it wasn't found in one sys.path entry. This cascading continues to work with 2.5. Phillip, can you take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537167&group_id=5470 From noreply at sourceforge.net Wed Aug 9 16:10:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 07:10:51 -0700 Subject: [ python-Bugs-1534765 ] logging's fileConfig causes KeyError on shutdown Message-ID: Bugs item #1534765, was opened at 2006-08-04 19:58 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534765&group_id=5470 Please note that this 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: mdbeachy (mdbeachy) Assigned to: Vinay Sajip (vsajip) Summary: logging's fileConfig causes KeyError on shutdown Initial Comment: If logging.config.fileConfig() is called after logging handlers already exist, a KeyError is thrown in the atexit call to logging.shutdown(). This looks like it's fixed in the 2.5 branch but since I've bothered to figure out what was going on I'm sending this in anyway. There still might be a 2.4.4, right? (Also, my fix looks better than what was done for 2.5, but I suppose the flush/close I added may not be necessary.) Attached is a demo and a patch against 2.4.3. Thanks, Mike ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-08-09 14:10 Message: Logged In: YES user_id=1126061 Bug confirmed in release24-maint. Patch looks good to me, although I think the developers prefer unified diffs, not contextual, just to keep in mind for the future. And also, I had to manually patch the Lib/logging/config.py file because for some reason, the paths in your patch all use lowercase letters. Thanks for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534765&group_id=5470 From noreply at sourceforge.net Wed Aug 9 16:33:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 07:33:46 -0700 Subject: [ python-Bugs-1537167 ] 2nd issue with need for speed patch Message-ID: Bugs item #1537167, was opened at 2006-08-09 07:01 Message generated for change (Comment added) made by robinbryce2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537167&group_id=5470 Please note that this 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: Robin Bryce (robinbryce2) Assigned to: Phillip J. Eby (pje) Summary: 2nd issue with need for speed patch Initial Comment: This is not a duplicate of the "realease manager pronouncement on 302 Fix needed" issue raised on pydev. If a custom importer is present, import.c skips the builtin import machinery if the find_module method of that importer returns None. For python 2.4.3 if find_module returns none the normal builtin machinery gets a lookin. The relevent change was the addition of a continue statement with svn commit r46372 (at around line 1283 of import.c on the trunk). I don't understand, in the face of this change, how pep 302 importers are expected to cascade. returning None from find_module is the way an importer says "no I can't load this module but I cant say for certain this means ImportError" isnt it ? One (unintended?) consequence of this change is the following corner case: As __import__ allows non dotted module names __import__('fakemod.a/b') *will* succede on python 2.4.3 provided b is a directory under the package a that contains an __init__.py. In python 2.5b3 this fails. I've atatched a detailed repro case of this particular corner case. ---------------------------------------------------------------------- >Comment By: Robin Bryce (robinbryce2) Date: 2006-08-09 15:33 Message: Logged In: YES user_id=1547259 The 'illeagal' module name is a red herring. The problem exists with leagal paths also:: Python 2.5b3 (trunk:51136, Aug 9 2006, 15:17:14) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from fakemod import urlpathimport >>> urlpathimport.install() >>> m=__import__('fakemod.a') *** fullname='fakemod.a' initpath='fakemod' *** Traceback (most recent call last): File "", line 1, in ImportError: No module named a >>> robin at rsb2-ubuntu:~/devel/blackmile$ python Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from fakemod import urlpathimport >>> urlpathimport.install() >>> m=__import__('fakemod.a') *** fullname='fakemod.a' initpath='fakemod' *** >>> Working on a test case. At present I think it is imposible for a 2.5 custom importer to choose *not* to import a standard python module by returning None from find_module. Because if it returns None the standard import is skipped. gbrandl, I think it was your commit that added the 'continue' statement, what is the reasoning behind making that optimisation ? Cheers, Robin ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-09 14:28 Message: Logged In: YES user_id=849994 Guido agreed that the 2.4 behavior is to be regarded as a bug: http://mail.python.org/pipermail/python-dev/2006-May/065174.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-09 13:27 Message: Logged In: YES user_id=21627 I'd say it is a bug that Python 2.4 allows non-dotted module names for __import__. Can you come up with a change in behaviour for "regular" module names? As for cascading: path importers doe not cascade. Per sys.path item, there can be at most one path importer. They "cascade" in the sense that search continues with other sys.path items if it wasn't found in one sys.path entry. This cascading continues to work with 2.5. Phillip, can you take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537167&group_id=5470 From noreply at sourceforge.net Wed Aug 9 16:34:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 07:34:16 -0700 Subject: [ python-Bugs-1535502 ] Python 2.5 windows builds should link hashlib with OpenSSL Message-ID: Bugs item #1535502, was opened at 2006-08-06 21:38 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535502&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Gregory P. Smith (greg) >Assigned to: Anthony Baxter (anthonybaxter) Summary: Python 2.5 windows builds should link hashlib with OpenSSL Initial Comment: The Windows builds of Python 2.5 need to be updated to build and link the hashlib modules with OpenSSL 0.9.8. The OpenSSL implementations of the hash algorithms are *much* faster (often 2-3x) than the fallback C implementations that python includes for use when OpenSSL isn't available. I just tested the python 2.5b3 installer on windows. its using the fallback versions rather than OpenSSL: here's a simple way to check from a running python: Without OpenSSL: >>> import hashlib >>> hashlib.sha1 With OpenSSL: >>> import hashlib >>> hashlib.sha1 (please use openssl 0.9.8; older versions don't include sha256 and sha512 implementations) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-09 16:34 Message: Logged In: YES user_id=21627 I changed the patch to support the Win64 build process, and added packaging support (msi.py). It looks fine to me now. Anthony, is this ok to apply? ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-08-08 09:48 Message: Logged In: YES user_id=413 attached is a patch that works for me on Win XP with MSVS 2003 (vc++ 7.1): build_hashlib_with_ssl-01.patch It does several things: build_ssl.py -- this is fixed to use do_masm.bat instead of a modified 32all.bat to build OpenSSL with x86 asm optimizations on Win32. It is also fixed to work when under a directory tree with spaces in the directory names. _ssl.mak -- since both _ssl and _hashlib depend on OpenSSL it made the most sense for both to be built by the same makefile. I added _hashlib's build here. _ssl.vcproj -- adds the dependancy on Modules/_hashopenssl.c Things still TODO - make sure _hashlib.pyd is added to the MSI installer. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-08-08 08:02 Message: Logged In: YES user_id=413 i've attached a patch to PCbuild/build_ssl.py that should build the assembly optimized OpenSSL on windows by default. Still todo: a _hashlib.vcproj file is needed. though wouldn't it be easier for me to just build _hashlib.pyd from within the _ssl.mak file? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535502&group_id=5470 From noreply at sourceforge.net Wed Aug 9 16:38:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 07:38:25 -0700 Subject: [ python-Bugs-1536825 ] distutils.sysconfig.get_config_h_filename gets useless file Message-ID: Bugs item #1536825, was opened at 2006-08-08 18:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536825&group_id=5470 Please note that this 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: 3rd Party >Status: Closed Resolution: None Priority: 5 Submitted By: Parzival Herzog (walt-kelly) Assigned to: Nobody/Anonymous (nobody) Summary: distutils.sysconfig.get_config_h_filename gets useless file Initial Comment: python -v: Python 2.4.1 (#2, Aug 25 2005, 18:20:57) [GCC 4.0.1 (4.0.1-2mdk for Mandriva Linux release 2006.0)] on linux2 While attempting to install cElementTree, the setup build failed because the setup.py attempted to parse the sysconfig.h file, using the filename provided by distutils.sysconfig.get_config_h_filename(). The file retrieved was "/usr/include/python2.4/pyconfig.h", which contains the text: ---------- #define _MULTIARCH_HEADER python2.4/pyconfig.h #include ---------- The cElementTree setup.py script then parsed this file, and attempted to configure itself as follows: -------- # determine suitable defines (based on Python's setup.py file) config_h = sysconfig.get_config_h_filename() config_h_vars = sysconfig.parse_config_h(open(config_h)) for feature_macro in ["HAVE_MEMMOVE", "HAVE_BCOPY"]: if config_h_vars.has_key(feature_macro): defines.append((feature_macro, "1")) -------- Since file with useful information is in "/usr/include/multiarch-i386-linux/python2.4/pyconfig.h", the subsequent build failed due to no HAVE_MEMMOVE or HAVE_BCOPY macro being defined. So, either 1) the cElementTree setup.py script is too clever for its own good, or is not clever enough, (tell that to F. Lundh) or 2) the sysconfig.get_config_h_filename is returning the wrong filename (i.e. a file that does not actually contain the needed configuration information), or 3) sysconfig.parse_config_h should, but does not follow the multi-arch-dispatch.h include, to get at the real sysconfig_h defines, or 4) Mandriva 2006 has messed up the Python distribution with that multi-arch-dispatch thing. I'm hoping that a solution is found rectifying either (2) or (3). ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-09 16:38 Message: Logged In: YES user_id=21627 My analysis is that it is (4). If Mandriva thinks it can change Python header files just like that and rearrange the layout of a Python installation, they also ought to fix distutils correspondingly. Before any code is added to distutils that supports this kind of installation, I'd like to see a PEP first stating the problem that is solved with that multi-arch-dispatch thing, and suggests a solution that will survive possible upcoming changes to that mechanism. Closing as a third-party bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536825&group_id=5470 From noreply at sourceforge.net Wed Aug 9 17:00:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 08:00:08 -0700 Subject: [ python-Bugs-1537445 ] urllib2 httplib _read_chunked timeout Message-ID: Bugs item #1537445, was opened at 2006-08-09 17:00 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537445&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: devloop (devloop) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 httplib _read_chunked timeout Initial Comment: Hello ! In a code of mine if have the lines : try: req = urllib2.Request(url) u = urllib2.urlopen(req) data=u.read() except urllib2.URLError,err: // error handling here The urllib2.URLError normally catchs the socket.timeout but someone send me a bug report of a tiemout error : File "/usr/lib/python2.4/socket.py", line 285, in read data = self._sock.recv(recv_size) File "/usr/lib/python2.4/httplib.py", line 460, in read return self._read_chunked(amt) File "/usr/lib/python2.4/httplib.py", line 495, in _read_chunked line = self.fp.readline() File "/usr/lib/python2.4/socket.py", line 325, in readline data = recv(1) socket.timeout: timed out Is it a bug with httplib and 'Content-Encoding: chunked' header ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537445&group_id=5470 From noreply at sourceforge.net Wed Aug 9 17:22:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 08:22:54 -0700 Subject: [ python-Bugs-1517990 ] IDLE on macosx keybindings need work Message-ID: Bugs item #1517990, was opened at 2006-07-06 04:26 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517990&group_id=5470 Please note that this 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.5 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Ronald Oussoren (ronaldoussoren) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: IDLE on macosx keybindings need work Initial Comment: There is a serious issue with the keybindings for IDLE on OSX: a lot of them don't work correctly. One example of a not-working key-binding is 'CMD-W', this should close the current window but doesn't. 'CMD-N' does create a new window though, so at least some keybindings work. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-09 11:22 Message: Logged In: YES user_id=149084 I see you added a comment to Python's NEWS. IDLE has its own NEWS file in idlelib: NEWS.txt! ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-25 16:36 Message: Logged In: YES user_id=580910 I've checked in OSX specific keybindings in revision 50833 This seems to fix all issues I had with the key bindings. The bindings are still not entirely compatible with that of Cocoa's textview[1], but that can't be helped. I'm therefore closing this issue. P.S. thanks for prodding me on this one, I might have let this slip beyond 2.5 otherwise. [1] See http://hcs.harvard.edu/~jrus/Site/System%20Bindings.html ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-25 15:26 Message: Logged In: YES user_id=580910 Cmd-W is fixed. I'm currenlty working my way through the keybindings and (a) check if they are correct for OSX and (b) if they actually work. Sorry about the missing NEWS items, I'll commit those soon. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-24 13:29 Message: Logged In: YES user_id=149084 I see you made a change yesterday to EditorWindow which appears to address the cmd-w bug. Could you make an entry in NEWS.txt when you modify IDLE's functionality? ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-18 08:09 Message: Logged In: YES user_id=580910 The keybinding definition itself seems to be correct (although I haven't reviewed it completely yet). The problem at this point is that IDLE doesn't respond to some (or even most) of them. I suspect that AquaTk is at fault here, it is really lousy at times. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-07-17 14:06 Message: Logged In: YES user_id=149084 Unfortunately, I don't have a Mac to work with. The current Mac keybindings were devised by Tony Lownds (tonylownds) during the transition to OSX. Would you like to create a new section in config-keys.def named OSX and work up some new bindings? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1517990&group_id=5470 From noreply at sourceforge.net Wed Aug 9 17:40:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 08:40:03 -0700 Subject: [ python-Bugs-1526585 ] Concatenation on a long string breaks Message-ID: Bugs item #1526585, was opened at 2006-07-21 17:18 Message generated for change (Settings changed) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Jp Calderone (kuran) Assigned to: Armin Rigo (arigo) Summary: Concatenation on a long string breaks Initial Comment: Consider this transcript: exarkun at charm:~/Projects/python/trunk$ ./python Python 2.5b2 (trunk:50698, Jul 18 2006, 10:08:36) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> x = 'x' * (2 ** 31 - 1) >>> x = x + 'x' Traceback (most recent call last): File "", line 1, in SystemError: Objects/stringobject.c:4103: bad argument to internal function >>> len(x) Traceback (most recent call last): File "", line 1, in NameError: name 'x' is not defined >>> I would expect some exception other than SystemError and for the locals namespace to not become corrupted. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-08-09 15:39 Message: Logged In: YES user_id=4771 Committed in rev 51178. Closing this report; the repetition problem is in another tracker and is mentioned in PEP 356 (the 2.5 release schedule). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-08 09:24 Message: Logged In: YES user_id=4771 I was away. I will try to get around to it before release candidate one. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-04 05:27 Message: Logged In: YES user_id=33168 Armin, yes that sounds reasonable. Please checkin as soon as possible now that the trunk is not frozen. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-27 08:48 Message: Logged In: YES user_id=4771 Almost missed kuran's note. Kuran: I suppose you meant to use 2**31 instead of 2**32, but you've found another important bug: >>> s = 'x' * (2**32-2) >>> N = len(s) >>> N 2147483647 >>> 2**32 4294967296L Argh! Another check is missing somewhere. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-27 08:38 Message: Logged In: YES user_id=4771 We could reuse the --memlimit option of regrtest in the following way: At the moment it makes no sense to specify a --memlimit larger than Py_ssize_t, like 3GB on 32-bit systems. At least test_bigmem fails completely in this case. From this it seems that the --memlimit actually tells, more precisely, how much of its *address space* the Python test process is allowed to consume. So the value should be clamped to a maximum of MAX(Py_ssize_t). This would solve the current test_bigmem issue. If we do so, then the condition "--memlimit >= MAX(Py_ssize_t)" is precisely what should be checked to know if we can run the test for the bug in the present tracker, and other tests of the same kind, which check what occurs when the *address space* is exhausted. In this way, specifying --memlimit=3G would enable either test_bigmem (on 64-bit systems) or some new test_filladdressspace (on 32-bit systems), as appropriate. Sounds reasonable? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-26 15:50 Message: Logged In: YES user_id=33168 You're correct that bigmem is primarily for testing int/Py_ssize_t. But it doesn't have to be. It has support for machines with largish amounts of memory (and limiting test runs). I didn't know where else to put such a test. I agree that this bug would only occur on 32-bit platforms. Most machines can't run it, so about the only other option I can think of would be to put it in it's own file and add a -u option. That seemed like even more work. I'm not tied to bigmem at all, but it would be nice to have a test for this somewhere. I'm sure there are a bunch of other places we have this sort of overflow and it would be good to test them somewhere. Do whatever you think is best. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-26 09:01 Message: Logged In: YES user_id=4771 I'm unsure about how the bigmem tests should be used. I think that I am not supposed to set a >2G limit on a 32-bit machine, right? When I do, I get 9 failures: 8 OverflowErrors and a stranger AssertionError in test_hash. I think that these tests are meant to test the int/Py_ssize_t difference on 64-bit machines instead. The bug this tracker is about only shows up on 32-bit machines. My concern is that if we add a test for the current bug in test_bigmem, then with a memory limit < 2GB the test is essentially skipped, and with a memory limit > 2GB then 9 other tests fail anyway. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-26 04:19 Message: Logged In: YES user_id=33168 Armin, can you check in your patch and backport? Also a news entry and a test in test_bigmem would be great. Thanks. If not let me know (assign to me) and I'll finish this up. This fix should be backported as well. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-07-25 20:06 Message: Logged In: YES user_id=366566 Tested Armin's patch, looks like it addresses the issue. One thing I noticed though, ('x' * (2 ** 32 - 2) + 'x') fails the same way ('x' * (2 ** 32 - 1) + 'x'). Don't really understand why, just thought I'd mention it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-25 18:25 Message: Logged In: YES user_id=4771 The check should be done before the variable is removed from the namespace, so that 'x' doesn't just disappear. Attached a patch that does this. Also, let's produce an exception consistent with what PyString_Concat() raises in the same case, which is an OverflowError instead of a MemoryError. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-25 03:57 Message: Logged In: YES user_id=31435 [Neal] > Tim since we know both lens are >= 0, is this test > sufficient for verifying overflow: > > Py_ssize_t new_len = v_len + w_len; > if (new_len < 0) { Right! That's all the new checking needed in string_concatenate(). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-25 03:46 Message: Logged In: YES user_id=33168 Attached a patch against 2.5. The patch should work against 2.4 too, but you will need to change all Py_ssize_t to int. Tim since we know both lens are >= 0, is this test sufficient for verifying overflow: Py_ssize_t new_len = v_len + w_len; if (new_len < 0) { Jp, can you test the patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-22 14:11 Message: Logged In: YES user_id=31435 Part of the problem appears to be that ceval.c's string_concatenate() doesn't check for overflow in the second argument here: if (_PyString_Resize(&v, v_len + w_len) != 0) The Windows malloc on my box returns NULL (and so Python raises MemoryError) on the initial: x = 'x' * (2 ** 31 - 1) attempt, so I never get that far. I'm afraid this is muddier in strange ways on Linux because the Linux malloc() is pathologically optimistic (can return a non-NULL value pointing at "memory" that can't actually be used for anything). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-07-22 09:00 Message: Logged In: YES user_id=6656 Confirmed with 2.4. Ouch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470 From noreply at sourceforge.net Wed Aug 9 17:42:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 08:42:38 -0700 Subject: [ python-Bugs-1526585 ] Concatenation on a long string breaks Message-ID: Bugs item #1526585, was opened at 2006-07-21 17:18 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Closed Resolution: Fixed Priority: 8 Submitted By: Jp Calderone (kuran) Assigned to: Armin Rigo (arigo) Summary: Concatenation on a long string breaks Initial Comment: Consider this transcript: exarkun at charm:~/Projects/python/trunk$ ./python Python 2.5b2 (trunk:50698, Jul 18 2006, 10:08:36) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> x = 'x' * (2 ** 31 - 1) >>> x = x + 'x' Traceback (most recent call last): File "", line 1, in SystemError: Objects/stringobject.c:4103: bad argument to internal function >>> len(x) Traceback (most recent call last): File "", line 1, in NameError: name 'x' is not defined >>> I would expect some exception other than SystemError and for the locals namespace to not become corrupted. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-08-09 15:42 Message: Logged In: YES user_id=4771 Committed in rev 51178. Closing this report; the repetition problem is in another tracker and is mentioned in PEP 356 (the 2.5 release schedule). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-09 15:39 Message: Logged In: YES user_id=4771 Committed in rev 51178. Closing this report; the repetition problem is in another tracker and is mentioned in PEP 356 (the 2.5 release schedule). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-08 09:24 Message: Logged In: YES user_id=4771 I was away. I will try to get around to it before release candidate one. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-04 05:27 Message: Logged In: YES user_id=33168 Armin, yes that sounds reasonable. Please checkin as soon as possible now that the trunk is not frozen. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-27 08:48 Message: Logged In: YES user_id=4771 Almost missed kuran's note. Kuran: I suppose you meant to use 2**31 instead of 2**32, but you've found another important bug: >>> s = 'x' * (2**32-2) >>> N = len(s) >>> N 2147483647 >>> 2**32 4294967296L Argh! Another check is missing somewhere. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-27 08:38 Message: Logged In: YES user_id=4771 We could reuse the --memlimit option of regrtest in the following way: At the moment it makes no sense to specify a --memlimit larger than Py_ssize_t, like 3GB on 32-bit systems. At least test_bigmem fails completely in this case. From this it seems that the --memlimit actually tells, more precisely, how much of its *address space* the Python test process is allowed to consume. So the value should be clamped to a maximum of MAX(Py_ssize_t). This would solve the current test_bigmem issue. If we do so, then the condition "--memlimit >= MAX(Py_ssize_t)" is precisely what should be checked to know if we can run the test for the bug in the present tracker, and other tests of the same kind, which check what occurs when the *address space* is exhausted. In this way, specifying --memlimit=3G would enable either test_bigmem (on 64-bit systems) or some new test_filladdressspace (on 32-bit systems), as appropriate. Sounds reasonable? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-26 15:50 Message: Logged In: YES user_id=33168 You're correct that bigmem is primarily for testing int/Py_ssize_t. But it doesn't have to be. It has support for machines with largish amounts of memory (and limiting test runs). I didn't know where else to put such a test. I agree that this bug would only occur on 32-bit platforms. Most machines can't run it, so about the only other option I can think of would be to put it in it's own file and add a -u option. That seemed like even more work. I'm not tied to bigmem at all, but it would be nice to have a test for this somewhere. I'm sure there are a bunch of other places we have this sort of overflow and it would be good to test them somewhere. Do whatever you think is best. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-26 09:01 Message: Logged In: YES user_id=4771 I'm unsure about how the bigmem tests should be used. I think that I am not supposed to set a >2G limit on a 32-bit machine, right? When I do, I get 9 failures: 8 OverflowErrors and a stranger AssertionError in test_hash. I think that these tests are meant to test the int/Py_ssize_t difference on 64-bit machines instead. The bug this tracker is about only shows up on 32-bit machines. My concern is that if we add a test for the current bug in test_bigmem, then with a memory limit < 2GB the test is essentially skipped, and with a memory limit > 2GB then 9 other tests fail anyway. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-26 04:19 Message: Logged In: YES user_id=33168 Armin, can you check in your patch and backport? Also a news entry and a test in test_bigmem would be great. Thanks. If not let me know (assign to me) and I'll finish this up. This fix should be backported as well. ---------------------------------------------------------------------- Comment By: Jp Calderone (kuran) Date: 2006-07-25 20:06 Message: Logged In: YES user_id=366566 Tested Armin's patch, looks like it addresses the issue. One thing I noticed though, ('x' * (2 ** 32 - 2) + 'x') fails the same way ('x' * (2 ** 32 - 1) + 'x'). Don't really understand why, just thought I'd mention it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-07-25 18:25 Message: Logged In: YES user_id=4771 The check should be done before the variable is removed from the namespace, so that 'x' doesn't just disappear. Attached a patch that does this. Also, let's produce an exception consistent with what PyString_Concat() raises in the same case, which is an OverflowError instead of a MemoryError. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-25 03:57 Message: Logged In: YES user_id=31435 [Neal] > Tim since we know both lens are >= 0, is this test > sufficient for verifying overflow: > > Py_ssize_t new_len = v_len + w_len; > if (new_len < 0) { Right! That's all the new checking needed in string_concatenate(). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-25 03:46 Message: Logged In: YES user_id=33168 Attached a patch against 2.5. The patch should work against 2.4 too, but you will need to change all Py_ssize_t to int. Tim since we know both lens are >= 0, is this test sufficient for verifying overflow: Py_ssize_t new_len = v_len + w_len; if (new_len < 0) { Jp, can you test the patch? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-07-22 14:11 Message: Logged In: YES user_id=31435 Part of the problem appears to be that ceval.c's string_concatenate() doesn't check for overflow in the second argument here: if (_PyString_Resize(&v, v_len + w_len) != 0) The Windows malloc on my box returns NULL (and so Python raises MemoryError) on the initial: x = 'x' * (2 ** 31 - 1) attempt, so I never get that far. I'm afraid this is muddier in strange ways on Linux because the Linux malloc() is pathologically optimistic (can return a non-NULL value pointing at "memory" that can't actually be used for anything). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-07-22 09:00 Message: Logged In: YES user_id=6656 Confirmed with 2.4. Ouch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1526585&group_id=5470 From noreply at sourceforge.net Wed Aug 9 17:50:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 08:50:47 -0700 Subject: [ python-Bugs-1537167 ] 2nd issue with need for speed patch Message-ID: Bugs item #1537167, was opened at 2006-08-09 07:01 Message generated for change (Comment added) made by robinbryce2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537167&group_id=5470 Please note that this 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: Robin Bryce (robinbryce2) Assigned to: Phillip J. Eby (pje) Summary: 2nd issue with need for speed patch Initial Comment: This is not a duplicate of the "realease manager pronouncement on 302 Fix needed" issue raised on pydev. If a custom importer is present, import.c skips the builtin import machinery if the find_module method of that importer returns None. For python 2.4.3 if find_module returns none the normal builtin machinery gets a lookin. The relevent change was the addition of a continue statement with svn commit r46372 (at around line 1283 of import.c on the trunk). I don't understand, in the face of this change, how pep 302 importers are expected to cascade. returning None from find_module is the way an importer says "no I can't load this module but I cant say for certain this means ImportError" isnt it ? One (unintended?) consequence of this change is the following corner case: As __import__ allows non dotted module names __import__('fakemod.a/b') *will* succede on python 2.4.3 provided b is a directory under the package a that contains an __init__.py. In python 2.5b3 this fails. I've atatched a detailed repro case of this particular corner case. ---------------------------------------------------------------------- >Comment By: Robin Bryce (robinbryce2) Date: 2006-08-09 16:50 Message: Logged In: YES user_id=1547259 I've tried the attatched test case patch against release24-maint and it passes. ---------------------------------------------------------------------- Comment By: Robin Bryce (robinbryce2) Date: 2006-08-09 15:33 Message: Logged In: YES user_id=1547259 The 'illeagal' module name is a red herring. The problem exists with leagal paths also:: Python 2.5b3 (trunk:51136, Aug 9 2006, 15:17:14) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from fakemod import urlpathimport >>> urlpathimport.install() >>> m=__import__('fakemod.a') *** fullname='fakemod.a' initpath='fakemod' *** Traceback (most recent call last): File "", line 1, in ImportError: No module named a >>> robin at rsb2-ubuntu:~/devel/blackmile$ python Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from fakemod import urlpathimport >>> urlpathimport.install() >>> m=__import__('fakemod.a') *** fullname='fakemod.a' initpath='fakemod' *** >>> Working on a test case. At present I think it is imposible for a 2.5 custom importer to choose *not* to import a standard python module by returning None from find_module. Because if it returns None the standard import is skipped. gbrandl, I think it was your commit that added the 'continue' statement, what is the reasoning behind making that optimisation ? Cheers, Robin ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-09 14:28 Message: Logged In: YES user_id=849994 Guido agreed that the 2.4 behavior is to be regarded as a bug: http://mail.python.org/pipermail/python-dev/2006-May/065174.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-09 13:27 Message: Logged In: YES user_id=21627 I'd say it is a bug that Python 2.4 allows non-dotted module names for __import__. Can you come up with a change in behaviour for "regular" module names? As for cascading: path importers doe not cascade. Per sys.path item, there can be at most one path importer. They "cascade" in the sense that search continues with other sys.path items if it wasn't found in one sys.path entry. This cascading continues to work with 2.5. Phillip, can you take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537167&group_id=5470 From noreply at sourceforge.net Wed Aug 9 18:13:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 09:13:42 -0700 Subject: [ python-Bugs-1488934 ] file.write + closed pipe = no error Message-ID: Bugs item #1488934, was opened at 2006-05-15 12:10 Message generated for change (Comment added) made by edemaine You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488934&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Erik Demaine (edemaine) Assigned to: A.M. Kuchling (akuchling) Summary: file.write + closed pipe = no error Initial Comment: I am writing a Python script on Linux that gets called via ssh (ssh hostname script.py) and I would like it to know when its stdout gets closed because the ssh connection gets killed. I assumed that it would suffice to write to stdout, and that I would get an error if stdout was no longer connected to anything. This is not the case, however. I believe it is because of incorrect error checking in Objects/fileobject.c's file_write. Consider this example: while True: __print 'Hello' __time.sleep (1) If this program is run via ssh and then the ssh connection dies, the program continues running forever (or at least, over 10 hours). No exceptions are thrown. In contrast, this example does die as soon as the ssh connection dies (within one second): while True: __os.write (1, 'Hello') __time.sleep (1) I claim that this is because os.write does proper error checking, but file.write seems not to. I was surprised to find this intricacy in fwrite(). Consider the attached C program, test.c. (Warning: If you run it, it will create a file /tmp/hello, and it will keep running until you kill it.) While the ssh connection remains open, fwrite() reports a length of 6 bytes written, ferror() reports no error, and errno remains 0. Once the ssh connection dies, fwrite() still reports a length of 6 bytes written (surprise!), but ferror(stdout) reports an error, and errno changes to 5 (EIO). So apparently one cannot tell from the return value of fwrite() alone whether the write actually succeeded; it seems necessary to call ferror() to determine whether the write caused an error. I think the only change necessary is on line 2443 of file_write() in Objects/fileobject.c (in svn version 46003): 2441 n2 = fwrite(s, 1, n, f->f_fp); 2442 Py_END_ALLOW_THREADS 2443 if (n2 != n) { 2444 PyErr_SetFromErrno(PyExc_IOError); 2445 clearerr(f->f_fp); I am not totally sure whether the "n2 != n" condition should be changed to "n2 != n || ferror (f->f_fp)" or simply "ferror (f->f_fp)", but I believe that the condition should be changed to one of these possibilities. The current behavior is wrong. Incidentally, you'll notice that the C code has to turn off signal SIGPIPE (like Python does) in order to not die right away. However, I could not get Python to die by re-enabling SIGPIPE. I tried "signal.signal (signal.SIGPIPE, signal.SIG_DFL)" and "signal.signal (signal.SIGPIPE, lambda x, y: sys.exit ())" and neither one caused death of the script when the ssh connection died. Perhaps I'm not using the signal module correctly? I am on Linux 2.6.11 on a two-CPU Intel Pentium 4, and I am running the latest Subversion version of Python, but my guess is that this error transcends most if not all versions of Python. ---------------------------------------------------------------------- >Comment By: Erik Demaine (edemaine) Date: 2006-08-09 12:13 Message: Logged In: YES user_id=265183 Just to clarify (as I reread your question): I'm killing the ssh via UNIX (or Cygwin) 'kill' command, not via CTRL-C. I didn't try, but it may be that CTRL-C works fine. ---------------------------------------------------------------------- Comment By: Erik Demaine (edemaine) Date: 2006-07-02 08:35 Message: Logged In: YES user_id=265183 A simple test case is this Python script (fleshed out from previous example), also attached: import sys, time while True: __print 'Hello' __sys.stdout.flush () __time.sleep (1) Save as blah.py on machine foo, run 'ssh foo python blah.py' on machine bar--you will see 'Hello' every second--then, in another shell on bar, kill the ssh process on bar. blah.py should still be running on foo. ('foo' and 'bar' can actually be the same machine.) The example from the original bug report that uses os.write() instead of print was an example that *does* work. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-03 16:16 Message: Logged In: YES user_id=11375 I agree with your analysis, and think your suggested fixes are correct. However, I'm unable to construct a small test case that exercises this bug. I can't even replicate the problem with SSH; when I run a remote script with SSH and then kill SSH with Ctrl-C, the write() gets a -1. Are you terminating SSH in some other way? (I'd really like to have a test case for this problem before committing the fix.) ---------------------------------------------------------------------- Comment By: Erik Demaine (edemaine) Date: 2006-05-15 12:26 Message: Logged In: YES user_id=265183 One more thing: fwrite() is used in a couple of other places, and I think the same comment applies to them. They are: - file_writelines() in Objects/fileobject.c - w_string() in Python/marshal.c doesn't seem to have any error checking? (At least no ferror() call in marhsal.c...) - string_print() in Objects/stringobject.c doesn't seem to have any error checking (but I'm not quite sure what this means in Python land). - flush_data() in Modules/_hotshot.c - array_tofile() in Modules/arraymodule.c - write_file() in Modules/cPickle.c - putshort(), putlong(), writeheader(), writetab() [and the functions that call them] in Modules/rgbimgmodule.c - svc_writefile() in Modules/svmodule.c ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1488934&group_id=5470 From noreply at sourceforge.net Wed Aug 9 18:14:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 09:14:57 -0700 Subject: [ python-Feature Requests-1534942 ] Print identical floats consistently Message-ID: Feature Requests item #1534942, was opened at 2006-08-04 23:19 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1534942&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Submitted By: Marc W. Abel (gihon) Assigned to: Nobody/Anonymous (nobody) Summary: Print identical floats consistently Initial Comment: Hello again and thank you, This is a rewrite of now-closed bug #1534769. As you know, >>> print .1 >>> print (.1,) give different results because the __str__ call from print becomes a __repr__ call on the tuple, and it stays a __repr__ beneath that point in any recursion. >From the previous discussion, we need behavior like this so that strings are quoted inside tuples. I suggest that print use a third builtin that is neither __str__ nor __repr__. The name isn't important, but suppose we call it __strep__ in this feature request. __strep__ would pass __strep__ down in the recursion, printing floats with __str__ and everything else with __repr__. This would then >>> print .1 and >>> print (.1,) with the same precision. Marc ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-08-09 09:14 Message: Logged In: YES user_id=341410 Please note that 'print non_string' is a convenience. Its output is neither part of the language spec, nor is the propagation of str/repr calls. If you want to control how items are formatted during print, you should use the built-in string formatting mechanisms. The standard 'print "%.1f"%(.1,)' and 'print "%(x).1f"%({x:.1})' works with all pythons, and there is an updated templating mechanism available in more recent Python versions. I'm not the last word on this, but I don't see an actual use-case that isn't satisfied by using built-in string-formatting. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1534942&group_id=5470 From noreply at sourceforge.net Wed Aug 9 21:12:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 12:12:58 -0700 Subject: [ python-Bugs-1537601 ] Installation on Windows Longhorn Message-ID: Bugs item #1537601, was opened at 2006-08-10 00:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537601&group_id=5470 Please note that this 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: O.R.Senthil Kumaran (orsenthil) Assigned to: Nobody/Anonymous (nobody) Summary: Installation on Windows Longhorn Initial Comment: Windows Longhorn is a next version of Microsft Windows. We have Beta builds of Longhorn in our labs. I tried installing Python 2.4.3 on Windows Longhorn, the Installation dialog box halts a setup dialog box which reads: "Please wait while the installer finishes determining your disk space requirements." Observed this on Python 2.4.3 as well as Python-2.5b3 ActivePython 2.4 however Installs fine. Please refer the screenshots attached. Thanks, Senthil ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537601&group_id=5470 From noreply at sourceforge.net Wed Aug 9 22:35:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 13:35:22 -0700 Subject: [ python-Feature Requests-1534942 ] Print identical floats consistently Message-ID: Feature Requests item #1534942, was opened at 2006-08-05 06:19 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1534942&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Submitted By: Marc W. Abel (gihon) Assigned to: Nobody/Anonymous (nobody) Summary: Print identical floats consistently Initial Comment: Hello again and thank you, This is a rewrite of now-closed bug #1534769. As you know, >>> print .1 >>> print (.1,) give different results because the __str__ call from print becomes a __repr__ call on the tuple, and it stays a __repr__ beneath that point in any recursion. >From the previous discussion, we need behavior like this so that strings are quoted inside tuples. I suggest that print use a third builtin that is neither __str__ nor __repr__. The name isn't important, but suppose we call it __strep__ in this feature request. __strep__ would pass __strep__ down in the recursion, printing floats with __str__ and everything else with __repr__. This would then >>> print .1 and >>> print (.1,) with the same precision. Marc ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-09 20:35 Message: Logged In: YES user_id=849994 I recommend closing this. Introducing yet another to-string magic function is not going to make things simpler, and who knows if the str/repr distinction is going to make it into 3.0 anyway. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-08-09 16:14 Message: Logged In: YES user_id=341410 Please note that 'print non_string' is a convenience. Its output is neither part of the language spec, nor is the propagation of str/repr calls. If you want to control how items are formatted during print, you should use the built-in string formatting mechanisms. The standard 'print "%.1f"%(.1,)' and 'print "%(x).1f"%({x:.1})' works with all pythons, and there is an updated templating mechanism available in more recent Python versions. I'm not the last word on this, but I don't see an actual use-case that isn't satisfied by using built-in string-formatting. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1534942&group_id=5470 From noreply at sourceforge.net Wed Aug 9 22:40:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 13:40:04 -0700 Subject: [ python-Bugs-1533491 ] C/API sec 10 is clipped Message-ID: Bugs item #1533491, was opened at 2006-08-02 22:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533491&group_id=5470 Please note that this 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: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: C/API sec 10 is clipped Initial Comment: As of 2.5b2, section 10 of the C/API reference manual seems clipped. Sections 10.4, 10.5, and 10.6 are at best placeholders, and 10.8 isn't even that. (It looks like they could be either on their own as sections, or inlined to an earlier section, and both places are TBD, but the section doesn't make this as obvious.) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-09 20:40 Message: Logged In: YES user_id=849994 Note that "as of 2.5b2" is misleading. It seems like the mentioned sections have never been written at all. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533491&group_id=5470 From noreply at sourceforge.net Wed Aug 9 23:13:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 14:13:38 -0700 Subject: [ python-Bugs-1537685 ] import on cElementTree on Windows Message-ID: Bugs item #1537685, was opened at 2006-08-09 17:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537685&group_id=5470 Please note that this 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: Thomas B Hickey (thomasbhickey) Assigned to: Nobody/Anonymous (nobody) Summary: import on cElementTree on Windows Initial Comment: run this one-line file on Windows 2000: import xml.etree.cElementTree It generates the message: usage: copy.py inputFile outputFile If you give it a couple of file names it at least reads in the first. --Th ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537685&group_id=5470 From noreply at sourceforge.net Wed Aug 9 23:58:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 14:58:12 -0700 Subject: [ python-Bugs-1112549 ] cgi.FieldStorage memory usage can spike in line-oriented ops Message-ID: Bugs item #1112549, was opened at 2005-01-30 08:40 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 Please note that this 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: 8 Submitted By: Chris McDonough (chrism) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.FieldStorage memory usage can spike in line-oriented ops Initial Comment: Various parts of cgi.FieldStorage call its "read_lines_to_outerboundary", "read_lines" and "skip_lines" methods. These methods use the "readline" method of the file object that represents an input stream. The input stream is typically data supplied by an untrusted source (such as a user uploading a file from a web browser). The input data is not required by the RFC 822/1521/1522/1867 specifications to contain any newline characters. For example, it is within the bounds of the specification to supply a a multipart/form-data input stream with a "file-data" part that consists of a 2GB string composed entirely of "x" characters (which happens to be something I did that led me to noticing this bug). The simplest fix is to make use of the "size" argument of the readline method of the file object where it is used within all parts of FieldStorage that make use of it. A patch against the Python 2.3.4 cgi.py module that does this is attached. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-09 17:58 Message: Logged In: YES user_id=6380 +1. minor nits: in the main patch: instead of + if line.endswith('\n'): + last_line_lfend = True + else: + last_line_lfend = False you can just use last_line_lfend = line.endswith('\n') in the unit test: instead of if type(a) != type(0): use if not isinstance(a, int): so that if some future release changes file.closed to return a bool (as it should :-) this test won't break. Is tehre a reason why you're not patching the fp.readline() call in parse_multipart()? It would seem to have the same issue (even if it isn't used in Zope :-). ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-08-07 13:51 Message: Logged In: YES user_id=32974 Yup, test/output/test_cgi did need fixing. Apologies, I did not understand the test regime. A new patch file named test_output_test_cgi- svn-50879.patch has been uploaded with the required change. regrtest.py now passes. As far as verify vs. vereq, the test_cgi module uses verify all over the place. I'm apt to not change all of those places, so to change it in just that one place is probably ineffective. Same for type comparison vs. isinstance. I'm trying to make the smallest change possible as opposed to refactoring the test module. I've uploaded a patch which contains a) the fix to cgi.py, b) the fix to test_cgi.py, and the fix to output/test_cgi. The stylistic change wrt to last_line_lfend is fine with me, but I'll leave that jugment to someone else. I'm not sure how to ensure the fix doesn't create other problems other than what has already been done by proving it still passes the tests it was subjected to in the "old" test suite and adds new tests that prove it no longer has the denial of service problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-07 01:50 Message: Logged In: YES user_id=33168 Doesn't this require a change to test/output/test_cgi or something like that? Does this test pass when run under regrtest.py ? The verify(x == y) should be vereq(x, y). type(a) != type(0), should be not isinstance(a, int). The last chunk of the patch in cgi.py should be: last_line_lfend = line.endswith('\n') rather than the 4 lines of if/else. I don't know if this patch really addresses the problem or creates other problems. However, if someone more knowledgable is confident about this patch, I'm fine with this going in. At this point, it might be better to wait for 2.5.1 though. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-07-27 17:42 Message: Logged In: YES user_id=32974 The files I've just uploaded are revisions to the cgi and test_cgi modules for the current state of the SVN trunk. If someone could apply these, it would be appreciated, or give me access and I'll be happy to. FTR, this is a bug which exposes systems which use the cgi.FieldStorage class (most Python web frameworks do) to a denial of service potential. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-02 23:00 Message: Logged In: YES user_id=32974 FYI, I'd be happy to do the merging here if you wanted to give me checkin access. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-02 22:42 Message: Logged In: YES user_id=32974 An updated test_cgi.py is attached. I test both the readline behavior and add a test for basic multipart parsing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 23:48 Message: Logged In: YES user_id=6380 Can I tweak you into uploading a unit test? ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-03-31 21:56 Message: Logged In: YES user_id=32974 Re: parse_multipart.. yes, it looks like there's no use fixing that as it just turns around and puts the line into a list.. it is vulnerable but just by virtue of its non-use of a tempfile, it appears doomed anyway for large requests. I don't know of anything that uses it. Good catch wrt boundary recognition bug, I'm uploading another patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 17:13 Message: Logged In: YES user_id=6380 Methinks that the fix isn't quite right: it would incorrectly recognize as a boundary a very long line starting with "--" followed by the appropriate random string at offset 2**16. This could probably be taken care of by adding a flag that is true initially and after that keeps track of whether the previous line ended in \n. Also, there's a call to fp.readline() in parse_multipart() that you didn't patch -- it wouldn't help because that code is saving the lines in a list anyway, but isn't that code vulnerable as well? Or is it not used? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 From noreply at sourceforge.net Thu Aug 10 00:20:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 15:20:01 -0700 Subject: [ python-Feature Requests-1537721 ] csv module: add header row to DictWriter Message-ID: Feature Requests item #1537721, was opened at 2006-08-10 10:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1537721&group_id=5470 Please note that this 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: ed_abraham (ed_abraham) Assigned to: Nobody/Anonymous (nobody) Summary: csv module: add header row to DictWriter Initial Comment: I use the DictWriter class from the csv module, and have to manually write the header row. A mindless chore which I would like to see eliminated. Can we have a writeheader method added to the class? Something like the following: def writeheader(self, headernames = {}): """Write a header row""" if not headernames: headernames = dict(zip(self.fieldnames, self.fieldnames)) self.writerow(headernames) This would let you either use the fieldnames directly, or supply your own pretty header names. Would be nice to have another keyword argument to DictWriter, 'header = False'. If header was true, then the __init__ method could call writeheader(). At the moment I have to write things like fields = ['a','b','c'] w = csv.DictWriter(fid, fields) w.writerow(dict(zip(fields, fields))) for row in rows: w.writerow(row) The proposed changes would let me write the simpler w = csv.DictWriter(fid, ['a','b','c'], header = True) for row in rows: w.writerow(row) A problem is that including a new keyword argument would break code which used position to fill the keyword arguments and to supply arguments through *args to the writer class. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1537721&group_id=5470 From noreply at sourceforge.net Thu Aug 10 00:23:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 15:23:43 -0700 Subject: [ python-Bugs-1112549 ] cgi.FieldStorage memory usage can spike in line-oriented ops Message-ID: Bugs item #1112549, was opened at 2005-01-30 08:40 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 Please note that this 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: 8 Submitted By: Chris McDonough (chrism) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.FieldStorage memory usage can spike in line-oriented ops Initial Comment: Various parts of cgi.FieldStorage call its "read_lines_to_outerboundary", "read_lines" and "skip_lines" methods. These methods use the "readline" method of the file object that represents an input stream. The input stream is typically data supplied by an untrusted source (such as a user uploading a file from a web browser). The input data is not required by the RFC 822/1521/1522/1867 specifications to contain any newline characters. For example, it is within the bounds of the specification to supply a a multipart/form-data input stream with a "file-data" part that consists of a 2GB string composed entirely of "x" characters (which happens to be something I did that led me to noticing this bug). The simplest fix is to make use of the "size" argument of the readline method of the file object where it is used within all parts of FieldStorage that make use of it. A patch against the Python 2.3.4 cgi.py module that does this is attached. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-09 18:23 Message: Logged In: YES user_id=6380 BTW it would be better if all patches were in a single file -- then you can delete the older patches (if SF lets you do that). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-09 17:58 Message: Logged In: YES user_id=6380 +1. minor nits: in the main patch: instead of + if line.endswith('\n'): + last_line_lfend = True + else: + last_line_lfend = False you can just use last_line_lfend = line.endswith('\n') in the unit test: instead of if type(a) != type(0): use if not isinstance(a, int): so that if some future release changes file.closed to return a bool (as it should :-) this test won't break. Is tehre a reason why you're not patching the fp.readline() call in parse_multipart()? It would seem to have the same issue (even if it isn't used in Zope :-). ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-08-07 13:51 Message: Logged In: YES user_id=32974 Yup, test/output/test_cgi did need fixing. Apologies, I did not understand the test regime. A new patch file named test_output_test_cgi- svn-50879.patch has been uploaded with the required change. regrtest.py now passes. As far as verify vs. vereq, the test_cgi module uses verify all over the place. I'm apt to not change all of those places, so to change it in just that one place is probably ineffective. Same for type comparison vs. isinstance. I'm trying to make the smallest change possible as opposed to refactoring the test module. I've uploaded a patch which contains a) the fix to cgi.py, b) the fix to test_cgi.py, and the fix to output/test_cgi. The stylistic change wrt to last_line_lfend is fine with me, but I'll leave that jugment to someone else. I'm not sure how to ensure the fix doesn't create other problems other than what has already been done by proving it still passes the tests it was subjected to in the "old" test suite and adds new tests that prove it no longer has the denial of service problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-07 01:50 Message: Logged In: YES user_id=33168 Doesn't this require a change to test/output/test_cgi or something like that? Does this test pass when run under regrtest.py ? The verify(x == y) should be vereq(x, y). type(a) != type(0), should be not isinstance(a, int). The last chunk of the patch in cgi.py should be: last_line_lfend = line.endswith('\n') rather than the 4 lines of if/else. I don't know if this patch really addresses the problem or creates other problems. However, if someone more knowledgable is confident about this patch, I'm fine with this going in. At this point, it might be better to wait for 2.5.1 though. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-07-27 17:42 Message: Logged In: YES user_id=32974 The files I've just uploaded are revisions to the cgi and test_cgi modules for the current state of the SVN trunk. If someone could apply these, it would be appreciated, or give me access and I'll be happy to. FTR, this is a bug which exposes systems which use the cgi.FieldStorage class (most Python web frameworks do) to a denial of service potential. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-02 23:00 Message: Logged In: YES user_id=32974 FYI, I'd be happy to do the merging here if you wanted to give me checkin access. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-02 22:42 Message: Logged In: YES user_id=32974 An updated test_cgi.py is attached. I test both the readline behavior and add a test for basic multipart parsing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 23:48 Message: Logged In: YES user_id=6380 Can I tweak you into uploading a unit test? ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-03-31 21:56 Message: Logged In: YES user_id=32974 Re: parse_multipart.. yes, it looks like there's no use fixing that as it just turns around and puts the line into a list.. it is vulnerable but just by virtue of its non-use of a tempfile, it appears doomed anyway for large requests. I don't know of anything that uses it. Good catch wrt boundary recognition bug, I'm uploading another patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 17:13 Message: Logged In: YES user_id=6380 Methinks that the fix isn't quite right: it would incorrectly recognize as a boundary a very long line starting with "--" followed by the appropriate random string at offset 2**16. This could probably be taken care of by adding a flag that is true initially and after that keeps track of whether the previous line ended in \n. Also, there's a call to fp.readline() in parse_multipart() that you didn't patch -- it wouldn't help because that code is saving the lines in a list anyway, but isn't that code vulnerable as well? Or is it not used? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 From noreply at sourceforge.net Thu Aug 10 01:33:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 16:33:50 -0700 Subject: [ python-Bugs-1537167 ] 2nd issue with need for speed patch Message-ID: Bugs item #1537167, was opened at 2006-08-09 08:01 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537167&group_id=5470 Please note that this 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: Robin Bryce (robinbryce2) Assigned to: Phillip J. Eby (pje) Summary: 2nd issue with need for speed patch Initial Comment: This is not a duplicate of the "realease manager pronouncement on 302 Fix needed" issue raised on pydev. If a custom importer is present, import.c skips the builtin import machinery if the find_module method of that importer returns None. For python 2.4.3 if find_module returns none the normal builtin machinery gets a lookin. The relevent change was the addition of a continue statement with svn commit r46372 (at around line 1283 of import.c on the trunk). I don't understand, in the face of this change, how pep 302 importers are expected to cascade. returning None from find_module is the way an importer says "no I can't load this module but I cant say for certain this means ImportError" isnt it ? One (unintended?) consequence of this change is the following corner case: As __import__ allows non dotted module names __import__('fakemod.a/b') *will* succede on python 2.4.3 provided b is a directory under the package a that contains an __init__.py. In python 2.5b3 this fails. I've atatched a detailed repro case of this particular corner case. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-10 01:33 Message: Logged In: YES user_id=21627 The patch is originally mine; it does not have to do much with the need-for-speed sprint. The rationale is to reduce the number of stat/open calls when loading a module and the directory doesn't even exist (e.g. for the first sys.path entry, which is python25.zip). It originally put True/False on sys.path_importer_cache. Philipp Eby changed it to put the NullImporter on path_importer_cache, and not fall back to the builtin import if the path importer returns None. It never was the intention of the entire machinery that such a fallback is implemented. Instead, it always should have continued with the next sys.path entry instead. If a path import claims responsibility for a sys.path entry, and then finds it cannot fulfill the responsibility, and wants to fall back to the traditional file-based lookup, it needs to implement that itself. I would advise against doing so, though, and make the path import reject responsibility for the sys.path entry in the first place if that entry really is an on-disk directory. ---------------------------------------------------------------------- Comment By: Robin Bryce (robinbryce2) Date: 2006-08-09 17:50 Message: Logged In: YES user_id=1547259 I've tried the attatched test case patch against release24-maint and it passes. ---------------------------------------------------------------------- Comment By: Robin Bryce (robinbryce2) Date: 2006-08-09 16:33 Message: Logged In: YES user_id=1547259 The 'illeagal' module name is a red herring. The problem exists with leagal paths also:: Python 2.5b3 (trunk:51136, Aug 9 2006, 15:17:14) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from fakemod import urlpathimport >>> urlpathimport.install() >>> m=__import__('fakemod.a') *** fullname='fakemod.a' initpath='fakemod' *** Traceback (most recent call last): File "", line 1, in ImportError: No module named a >>> robin at rsb2-ubuntu:~/devel/blackmile$ python Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from fakemod import urlpathimport >>> urlpathimport.install() >>> m=__import__('fakemod.a') *** fullname='fakemod.a' initpath='fakemod' *** >>> Working on a test case. At present I think it is imposible for a 2.5 custom importer to choose *not* to import a standard python module by returning None from find_module. Because if it returns None the standard import is skipped. gbrandl, I think it was your commit that added the 'continue' statement, what is the reasoning behind making that optimisation ? Cheers, Robin ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-09 15:28 Message: Logged In: YES user_id=849994 Guido agreed that the 2.4 behavior is to be regarded as a bug: http://mail.python.org/pipermail/python-dev/2006-May/065174.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-09 14:27 Message: Logged In: YES user_id=21627 I'd say it is a bug that Python 2.4 allows non-dotted module names for __import__. Can you come up with a change in behaviour for "regular" module names? As for cascading: path importers doe not cascade. Per sys.path item, there can be at most one path importer. They "cascade" in the sense that search continues with other sys.path items if it wasn't found in one sys.path entry. This cascading continues to work with 2.5. Phillip, can you take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537167&group_id=5470 From noreply at sourceforge.net Thu Aug 10 01:37:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 16:37:13 -0700 Subject: [ python-Bugs-1537601 ] Installation on Windows Longhorn Message-ID: Bugs item #1537601, was opened at 2006-08-09 21:12 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537601&group_id=5470 Please note that this 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: Duplicate Priority: 5 Submitted By: O.R.Senthil Kumaran (orsenthil) Assigned to: Nobody/Anonymous (nobody) Summary: Installation on Windows Longhorn Initial Comment: Windows Longhorn is a next version of Microsft Windows. We have Beta builds of Longhorn in our labs. I tried installing Python 2.4.3 on Windows Longhorn, the Installation dialog box halts a setup dialog box which reads: "Please wait while the installer finishes determining your disk space requirements." Observed this on Python 2.4.3 as well as Python-2.5b3 ActivePython 2.4 however Installs fine. Please refer the screenshots attached. Thanks, Senthil ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-10 01:37 Message: Logged In: YES user_id=21627 This is a duplicate of http://python.org/sf/1512604 Please comment there if you have further remarks. If you are a beta tester of Vista/Longhorn Server, please report this as a bug to Microsoft; I believe it is a bug in Installer 4.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537601&group_id=5470 From noreply at sourceforge.net Thu Aug 10 03:40:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Aug 2006 18:40:24 -0700 Subject: [ python-Bugs-1224621 ] tokenize module does not detect inconsistent dedents Message-ID: Bugs item #1224621, was opened at 2005-06-21 02:10 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224621&group_id=5470 Please note that this 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: Danny Yoo (dyoo) >Assigned to: Raymond Hettinger (rhettinger) Summary: tokenize module does not detect inconsistent dedents Initial Comment: The attached code snippet 'testcase.py' should produce an IndentationError, but does not. The code in tokenize.py is too trusting, and needs to add a check against bad indentation as it yields DEDENT tokens. I'm including a diff to tokenize.py that should at least raise an exception on bad indentation like this. Just in case, I'm including testcase.py here too: ------ import tokenize from StringIO import StringIO sampleBadText = """ def foo(): bar baz """ print list(tokenize.generate_tokens( StringIO(sampleBadText).readline)) ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-09 21:40 Message: Logged In: YES user_id=149084 Tokenize Rev 39046 21Jun05 breaks tabnanny. tabnanny doesn't handle the IndentationError exception when tokenize detects a dedent. I patched up ScriptBinding.py in IDLE. The IndentationError probably should pass the same parms as TokenError and tabnanny should catch it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-02 08:40 Message: Logged In: YES user_id=4771 Here is a proposed patch. It relaxes the dedent policy a bit. It assumes that the first line may already have some initial indentation, as is the case when tokenizing from the middle of a file (as inspect.getsource() does). It should also be back-ported to 2.4, given that the previous patch was. For 2.4, only the non-test part of the patch applies cleanly; I suggest to ignore the test part and just apply it, given that there are much more tests in 2.5 for inspect.getsource() anyway. The whole issue of inspect.getsource() being muddy anyway, I will go ahead and check this patch in unless someone spots a problem. For now the previously-applied patch makes parts of PyPy break with an uncaught IndentationError. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-02 08:10 Message: Logged In: YES user_id=4771 Reopening this bug report: this might fix the problem at hand, but it breaks inspect.getsource() on cases where it used to work. See attached example. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-21 03:54 Message: Logged In: YES user_id=80475 Fixed. See Lib/tokenize.py 1.38 and 1.36.4.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224621&group_id=5470 From noreply at sourceforge.net Thu Aug 10 09:23:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Aug 2006 00:23:44 -0700 Subject: [ python-Bugs-1436226 ] fix inplace assignment for immutable sequences Message-ID: Bugs item #1436226, was opened at 2006-02-21 22:11 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436226&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 6 Submitted By: Georg Brandl (gbrandl) Assigned to: Nobody/Anonymous (nobody) Summary: fix inplace assignment for immutable sequences Initial Comment: Currently: py> tup = ([], ) py> tup[0] += [1] Traceback (most recent call last): File "", line 1, in ? TypeError: object doesn't support item assignment py> tup ([1],) With this patch, no exception will be raised when the item one wants to assign is already there in the tuple. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-10 07:23 Message: Logged In: YES user_id=849994 This is actually not supposed to work, says Guido. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-02-22 21:20 Message: Logged In: YES user_id=849994 You're right with the error handling *shame*. I had written the patch a few months ago and just posted it without looking at it again. Well, I don't think I'm able to come up with a new patch only for a couple of days. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-02-22 01:44 Message: Logged In: YES user_id=6380 I see no error handling from the PySequence_GetItem() call; if this causes an error it should take precedence over the TypeError we're about to raise (IOW we shouldn't raise the TypeError). Also, shouldn't the same fix be made for attribute assignment? Finally -- doing this in PySequence_SetItem is too broad. Code like this passes without error: t = (1, 2) t[0] = t[0] That can't be right! You need to find a code path that's only taken for += and friends. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1436226&group_id=5470 From noreply at sourceforge.net Thu Aug 10 09:37:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Aug 2006 00:37:38 -0700 Subject: [ python-Bugs-1537685 ] import on cElementTree on Windows Message-ID: Bugs item #1537685, was opened at 2006-08-09 21:13 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537685&group_id=5470 Please note that this 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: Pending Resolution: None Priority: 5 Submitted By: Thomas B Hickey (thomasbhickey) Assigned to: Nobody/Anonymous (nobody) Summary: import on cElementTree on Windows Initial Comment: run this one-line file on Windows 2000: import xml.etree.cElementTree It generates the message: usage: copy.py inputFile outputFile If you give it a couple of file names it at least reads in the first. --Th ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-10 07:37 Message: Logged In: YES user_id=849994 Could you provide more information? The string "usage: copy.py" exists nowhere in the Python source distribution, so I think it must be something on your end. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537685&group_id=5470 From noreply at sourceforge.net Thu Aug 10 13:08:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Aug 2006 04:08:44 -0700 Subject: [ python-Bugs-1112549 ] cgi.FieldStorage memory usage can spike in line-oriented ops Message-ID: Bugs item #1112549, was opened at 2005-01-30 08:40 Message generated for change (Comment added) made by chrism You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 Please note that this 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: 8 Submitted By: Chris McDonough (chrism) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.FieldStorage memory usage can spike in line-oriented ops Initial Comment: Various parts of cgi.FieldStorage call its "read_lines_to_outerboundary", "read_lines" and "skip_lines" methods. These methods use the "readline" method of the file object that represents an input stream. The input stream is typically data supplied by an untrusted source (such as a user uploading a file from a web browser). The input data is not required by the RFC 822/1521/1522/1867 specifications to contain any newline characters. For example, it is within the bounds of the specification to supply a a multipart/form-data input stream with a "file-data" part that consists of a 2GB string composed entirely of "x" characters (which happens to be something I did that led me to noticing this bug). The simplest fix is to make use of the "size" argument of the readline method of the file object where it is used within all parts of FieldStorage that make use of it. A patch against the Python 2.3.4 cgi.py module that does this is attached. ---------------------------------------------------------------------- >Comment By: Chris McDonough (chrism) Date: 2006-08-10 07:08 Message: Logged In: YES user_id=32974 wrt parse_multipart: this function just turns around and puts the output from readline() into a list, as opposed to FieldStorage, which writes its chunked output to a tempfile, so just adding an argument to readline within it would not be useful. We'd only be able to fix the memory consumption issue in parse_multipart if we were to make it also use a tempfile, but it's not clear that *not* writing a tempfile isn't its expected behavior as the docs for parse_multipart state: Returns a dictionary just like parse_qs() keys are the field names, each value is a list of values for that field. This is easy to use but not much good if you are expecting megabytes to be uploaded -- in that case, use the FieldStorage class instead which is much more flexible. Is it OK to write a tempfile in this function (e.g. does that make it not useful on stuff like embedded systems)? If not, maybe we should just deprecate parse_multipart? I do find things that use it if I google hard enough but there are only 187 hits when I google for "cgi.parse_multipart" and 53,600 hits when I google for "cgi.FieldStorage". I'm uploading another file with your style change suggestions. It bundles all fixes to cgi.py, test_cgi.py, and test_cgi and includes the style changes, but does nothing about parse_multipart. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-09 18:23 Message: Logged In: YES user_id=6380 BTW it would be better if all patches were in a single file -- then you can delete the older patches (if SF lets you do that). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-09 17:58 Message: Logged In: YES user_id=6380 +1. minor nits: in the main patch: instead of + if line.endswith('\n'): + last_line_lfend = True + else: + last_line_lfend = False you can just use last_line_lfend = line.endswith('\n') in the unit test: instead of if type(a) != type(0): use if not isinstance(a, int): so that if some future release changes file.closed to return a bool (as it should :-) this test won't break. Is tehre a reason why you're not patching the fp.readline() call in parse_multipart()? It would seem to have the same issue (even if it isn't used in Zope :-). ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-08-07 13:51 Message: Logged In: YES user_id=32974 Yup, test/output/test_cgi did need fixing. Apologies, I did not understand the test regime. A new patch file named test_output_test_cgi- svn-50879.patch has been uploaded with the required change. regrtest.py now passes. As far as verify vs. vereq, the test_cgi module uses verify all over the place. I'm apt to not change all of those places, so to change it in just that one place is probably ineffective. Same for type comparison vs. isinstance. I'm trying to make the smallest change possible as opposed to refactoring the test module. I've uploaded a patch which contains a) the fix to cgi.py, b) the fix to test_cgi.py, and the fix to output/test_cgi. The stylistic change wrt to last_line_lfend is fine with me, but I'll leave that jugment to someone else. I'm not sure how to ensure the fix doesn't create other problems other than what has already been done by proving it still passes the tests it was subjected to in the "old" test suite and adds new tests that prove it no longer has the denial of service problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-07 01:50 Message: Logged In: YES user_id=33168 Doesn't this require a change to test/output/test_cgi or something like that? Does this test pass when run under regrtest.py ? The verify(x == y) should be vereq(x, y). type(a) != type(0), should be not isinstance(a, int). The last chunk of the patch in cgi.py should be: last_line_lfend = line.endswith('\n') rather than the 4 lines of if/else. I don't know if this patch really addresses the problem or creates other problems. However, if someone more knowledgable is confident about this patch, I'm fine with this going in. At this point, it might be better to wait for 2.5.1 though. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-07-27 17:42 Message: Logged In: YES user_id=32974 The files I've just uploaded are revisions to the cgi and test_cgi modules for the current state of the SVN trunk. If someone could apply these, it would be appreciated, or give me access and I'll be happy to. FTR, this is a bug which exposes systems which use the cgi.FieldStorage class (most Python web frameworks do) to a denial of service potential. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-02 23:00 Message: Logged In: YES user_id=32974 FYI, I'd be happy to do the merging here if you wanted to give me checkin access. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-02 22:42 Message: Logged In: YES user_id=32974 An updated test_cgi.py is attached. I test both the readline behavior and add a test for basic multipart parsing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 23:48 Message: Logged In: YES user_id=6380 Can I tweak you into uploading a unit test? ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-03-31 21:56 Message: Logged In: YES user_id=32974 Re: parse_multipart.. yes, it looks like there's no use fixing that as it just turns around and puts the line into a list.. it is vulnerable but just by virtue of its non-use of a tempfile, it appears doomed anyway for large requests. I don't know of anything that uses it. Good catch wrt boundary recognition bug, I'm uploading another patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 17:13 Message: Logged In: YES user_id=6380 Methinks that the fix isn't quite right: it would incorrectly recognize as a boundary a very long line starting with "--" followed by the appropriate random string at offset 2**16. This could probably be taken care of by adding a flag that is true initially and after that keeps track of whether the previous line ended in \n. Also, there's a call to fp.readline() in parse_multipart() that you didn't patch -- it wouldn't help because that code is saving the lines in a list anyway, but isn't that code vulnerable as well? Or is it not used? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 From noreply at sourceforge.net Thu Aug 10 14:58:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Aug 2006 05:58:12 -0700 Subject: [ python-Bugs-1537685 ] import on cElementTree on Windows Message-ID: Bugs item #1537685, was opened at 2006-08-09 17:13 Message generated for change (Settings changed) made by thomasbhickey You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537685&group_id=5470 Please note that this 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: Thomas B Hickey (thomasbhickey) Assigned to: Nobody/Anonymous (nobody) Summary: import on cElementTree on Windows Initial Comment: run this one-line file on Windows 2000: import xml.etree.cElementTree It generates the message: usage: copy.py inputFile outputFile If you give it a couple of file names it at least reads in the first. --Th ---------------------------------------------------------------------- >Comment By: Thomas B Hickey (thomasbhickey) Date: 2006-08-10 08:58 Message: Logged In: YES user_id=274109 OK, the text is coming from a script 'copy.py' that is in the same directory as the file with the import of xml.etree.cElementTree. If I delete my copy.py (and it's associated copy.pyc) then I don't see the message. I just installed 2.5b3 and still get the same behavior. Somehow the import seems to be running my copy.pyc script. --Th ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-10 03:37 Message: Logged In: YES user_id=849994 Could you provide more information? The string "usage: copy.py" exists nowhere in the Python source distribution, so I think it must be something on your end. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537685&group_id=5470 From noreply at sourceforge.net Thu Aug 10 15:02:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Aug 2006 06:02:02 -0700 Subject: [ python-Bugs-1537685 ] import on cElementTree on Windows Message-ID: Bugs item #1537685, was opened at 2006-08-09 21:13 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537685&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Thomas B Hickey (thomasbhickey) Assigned to: Nobody/Anonymous (nobody) Summary: import on cElementTree on Windows Initial Comment: run this one-line file on Windows 2000: import xml.etree.cElementTree It generates the message: usage: copy.py inputFile outputFile If you give it a couple of file names it at least reads in the first. --Th ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-10 13:02 Message: Logged In: YES user_id=849994 This is because the ElementTree package imports the copy module (which is a Python standard module). It's the same effect as having an "os.py" file in the current directory and doing "import os". ---------------------------------------------------------------------- Comment By: Thomas B Hickey (thomasbhickey) Date: 2006-08-10 12:58 Message: Logged In: YES user_id=274109 OK, the text is coming from a script 'copy.py' that is in the same directory as the file with the import of xml.etree.cElementTree. If I delete my copy.py (and it's associated copy.pyc) then I don't see the message. I just installed 2.5b3 and still get the same behavior. Somehow the import seems to be running my copy.pyc script. --Th ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-10 07:37 Message: Logged In: YES user_id=849994 Could you provide more information? The string "usage: copy.py" exists nowhere in the Python source distribution, so I think it must be something on your end. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537685&group_id=5470 From noreply at sourceforge.net Thu Aug 10 16:24:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Aug 2006 07:24:13 -0700 Subject: [ python-Bugs-1112549 ] cgi.FieldStorage memory usage can spike in line-oriented ops Message-ID: Bugs item #1112549, was opened at 2005-01-30 08:40 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 Please note that this 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: 8 Submitted By: Chris McDonough (chrism) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.FieldStorage memory usage can spike in line-oriented ops Initial Comment: Various parts of cgi.FieldStorage call its "read_lines_to_outerboundary", "read_lines" and "skip_lines" methods. These methods use the "readline" method of the file object that represents an input stream. The input stream is typically data supplied by an untrusted source (such as a user uploading a file from a web browser). The input data is not required by the RFC 822/1521/1522/1867 specifications to contain any newline characters. For example, it is within the bounds of the specification to supply a a multipart/form-data input stream with a "file-data" part that consists of a 2GB string composed entirely of "x" characters (which happens to be something I did that led me to noticing this bug). The simplest fix is to make use of the "size" argument of the readline method of the file object where it is used within all parts of FieldStorage that make use of it. A patch against the Python 2.3.4 cgi.py module that does this is attached. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-10 10:24 Message: Logged In: YES user_id=6380 OK, let's forget about parse_multipart(). Feel free to add a doc patch and a comment that deprecate it (actual warnings are not a good idea IMO). ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-08-10 07:08 Message: Logged In: YES user_id=32974 wrt parse_multipart: this function just turns around and puts the output from readline() into a list, as opposed to FieldStorage, which writes its chunked output to a tempfile, so just adding an argument to readline within it would not be useful. We'd only be able to fix the memory consumption issue in parse_multipart if we were to make it also use a tempfile, but it's not clear that *not* writing a tempfile isn't its expected behavior as the docs for parse_multipart state: Returns a dictionary just like parse_qs() keys are the field names, each value is a list of values for that field. This is easy to use but not much good if you are expecting megabytes to be uploaded -- in that case, use the FieldStorage class instead which is much more flexible. Is it OK to write a tempfile in this function (e.g. does that make it not useful on stuff like embedded systems)? If not, maybe we should just deprecate parse_multipart? I do find things that use it if I google hard enough but there are only 187 hits when I google for "cgi.parse_multipart" and 53,600 hits when I google for "cgi.FieldStorage". I'm uploading another file with your style change suggestions. It bundles all fixes to cgi.py, test_cgi.py, and test_cgi and includes the style changes, but does nothing about parse_multipart. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-09 18:23 Message: Logged In: YES user_id=6380 BTW it would be better if all patches were in a single file -- then you can delete the older patches (if SF lets you do that). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-09 17:58 Message: Logged In: YES user_id=6380 +1. minor nits: in the main patch: instead of + if line.endswith('\n'): + last_line_lfend = True + else: + last_line_lfend = False you can just use last_line_lfend = line.endswith('\n') in the unit test: instead of if type(a) != type(0): use if not isinstance(a, int): so that if some future release changes file.closed to return a bool (as it should :-) this test won't break. Is tehre a reason why you're not patching the fp.readline() call in parse_multipart()? It would seem to have the same issue (even if it isn't used in Zope :-). ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-08-07 13:51 Message: Logged In: YES user_id=32974 Yup, test/output/test_cgi did need fixing. Apologies, I did not understand the test regime. A new patch file named test_output_test_cgi- svn-50879.patch has been uploaded with the required change. regrtest.py now passes. As far as verify vs. vereq, the test_cgi module uses verify all over the place. I'm apt to not change all of those places, so to change it in just that one place is probably ineffective. Same for type comparison vs. isinstance. I'm trying to make the smallest change possible as opposed to refactoring the test module. I've uploaded a patch which contains a) the fix to cgi.py, b) the fix to test_cgi.py, and the fix to output/test_cgi. The stylistic change wrt to last_line_lfend is fine with me, but I'll leave that jugment to someone else. I'm not sure how to ensure the fix doesn't create other problems other than what has already been done by proving it still passes the tests it was subjected to in the "old" test suite and adds new tests that prove it no longer has the denial of service problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-07 01:50 Message: Logged In: YES user_id=33168 Doesn't this require a change to test/output/test_cgi or something like that? Does this test pass when run under regrtest.py ? The verify(x == y) should be vereq(x, y). type(a) != type(0), should be not isinstance(a, int). The last chunk of the patch in cgi.py should be: last_line_lfend = line.endswith('\n') rather than the 4 lines of if/else. I don't know if this patch really addresses the problem or creates other problems. However, if someone more knowledgable is confident about this patch, I'm fine with this going in. At this point, it might be better to wait for 2.5.1 though. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-07-27 17:42 Message: Logged In: YES user_id=32974 The files I've just uploaded are revisions to the cgi and test_cgi modules for the current state of the SVN trunk. If someone could apply these, it would be appreciated, or give me access and I'll be happy to. FTR, this is a bug which exposes systems which use the cgi.FieldStorage class (most Python web frameworks do) to a denial of service potential. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-02 23:00 Message: Logged In: YES user_id=32974 FYI, I'd be happy to do the merging here if you wanted to give me checkin access. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-02 22:42 Message: Logged In: YES user_id=32974 An updated test_cgi.py is attached. I test both the readline behavior and add a test for basic multipart parsing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 23:48 Message: Logged In: YES user_id=6380 Can I tweak you into uploading a unit test? ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-03-31 21:56 Message: Logged In: YES user_id=32974 Re: parse_multipart.. yes, it looks like there's no use fixing that as it just turns around and puts the line into a list.. it is vulnerable but just by virtue of its non-use of a tempfile, it appears doomed anyway for large requests. I don't know of anything that uses it. Good catch wrt boundary recognition bug, I'm uploading another patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 17:13 Message: Logged In: YES user_id=6380 Methinks that the fix isn't quite right: it would incorrectly recognize as a boundary a very long line starting with "--" followed by the appropriate random string at offset 2**16. This could probably be taken care of by adding a flag that is true initially and after that keeps track of whether the previous line ended in \n. Also, there's a call to fp.readline() in parse_multipart() that you didn't patch -- it wouldn't help because that code is saving the lines in a list anyway, but isn't that code vulnerable as well? Or is it not used? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 From noreply at sourceforge.net Thu Aug 10 19:13:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Aug 2006 10:13:04 -0700 Subject: [ python-Bugs-1112549 ] cgi.FieldStorage memory usage can spike in line-oriented ops Message-ID: Bugs item #1112549, was opened at 2005-01-30 08:40 Message generated for change (Settings changed) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 Please note that this 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: Accepted Priority: 8 Submitted By: Chris McDonough (chrism) >Assigned to: Guido van Rossum (gvanrossum) Summary: cgi.FieldStorage memory usage can spike in line-oriented ops Initial Comment: Various parts of cgi.FieldStorage call its "read_lines_to_outerboundary", "read_lines" and "skip_lines" methods. These methods use the "readline" method of the file object that represents an input stream. The input stream is typically data supplied by an untrusted source (such as a user uploading a file from a web browser). The input data is not required by the RFC 822/1521/1522/1867 specifications to contain any newline characters. For example, it is within the bounds of the specification to supply a a multipart/form-data input stream with a "file-data" part that consists of a 2GB string composed entirely of "x" characters (which happens to be something I did that led me to noticing this bug). The simplest fix is to make use of the "size" argument of the readline method of the file object where it is used within all parts of FieldStorage that make use of it. A patch against the Python 2.3.4 cgi.py module that does this is attached. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-10 10:24 Message: Logged In: YES user_id=6380 OK, let's forget about parse_multipart(). Feel free to add a doc patch and a comment that deprecate it (actual warnings are not a good idea IMO). ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-08-10 07:08 Message: Logged In: YES user_id=32974 wrt parse_multipart: this function just turns around and puts the output from readline() into a list, as opposed to FieldStorage, which writes its chunked output to a tempfile, so just adding an argument to readline within it would not be useful. We'd only be able to fix the memory consumption issue in parse_multipart if we were to make it also use a tempfile, but it's not clear that *not* writing a tempfile isn't its expected behavior as the docs for parse_multipart state: Returns a dictionary just like parse_qs() keys are the field names, each value is a list of values for that field. This is easy to use but not much good if you are expecting megabytes to be uploaded -- in that case, use the FieldStorage class instead which is much more flexible. Is it OK to write a tempfile in this function (e.g. does that make it not useful on stuff like embedded systems)? If not, maybe we should just deprecate parse_multipart? I do find things that use it if I google hard enough but there are only 187 hits when I google for "cgi.parse_multipart" and 53,600 hits when I google for "cgi.FieldStorage". I'm uploading another file with your style change suggestions. It bundles all fixes to cgi.py, test_cgi.py, and test_cgi and includes the style changes, but does nothing about parse_multipart. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-09 18:23 Message: Logged In: YES user_id=6380 BTW it would be better if all patches were in a single file -- then you can delete the older patches (if SF lets you do that). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-09 17:58 Message: Logged In: YES user_id=6380 +1. minor nits: in the main patch: instead of + if line.endswith('\n'): + last_line_lfend = True + else: + last_line_lfend = False you can just use last_line_lfend = line.endswith('\n') in the unit test: instead of if type(a) != type(0): use if not isinstance(a, int): so that if some future release changes file.closed to return a bool (as it should :-) this test won't break. Is tehre a reason why you're not patching the fp.readline() call in parse_multipart()? It would seem to have the same issue (even if it isn't used in Zope :-). ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-08-07 13:51 Message: Logged In: YES user_id=32974 Yup, test/output/test_cgi did need fixing. Apologies, I did not understand the test regime. A new patch file named test_output_test_cgi- svn-50879.patch has been uploaded with the required change. regrtest.py now passes. As far as verify vs. vereq, the test_cgi module uses verify all over the place. I'm apt to not change all of those places, so to change it in just that one place is probably ineffective. Same for type comparison vs. isinstance. I'm trying to make the smallest change possible as opposed to refactoring the test module. I've uploaded a patch which contains a) the fix to cgi.py, b) the fix to test_cgi.py, and the fix to output/test_cgi. The stylistic change wrt to last_line_lfend is fine with me, but I'll leave that jugment to someone else. I'm not sure how to ensure the fix doesn't create other problems other than what has already been done by proving it still passes the tests it was subjected to in the "old" test suite and adds new tests that prove it no longer has the denial of service problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-07 01:50 Message: Logged In: YES user_id=33168 Doesn't this require a change to test/output/test_cgi or something like that? Does this test pass when run under regrtest.py ? The verify(x == y) should be vereq(x, y). type(a) != type(0), should be not isinstance(a, int). The last chunk of the patch in cgi.py should be: last_line_lfend = line.endswith('\n') rather than the 4 lines of if/else. I don't know if this patch really addresses the problem or creates other problems. However, if someone more knowledgable is confident about this patch, I'm fine with this going in. At this point, it might be better to wait for 2.5.1 though. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-07-27 17:42 Message: Logged In: YES user_id=32974 The files I've just uploaded are revisions to the cgi and test_cgi modules for the current state of the SVN trunk. If someone could apply these, it would be appreciated, or give me access and I'll be happy to. FTR, this is a bug which exposes systems which use the cgi.FieldStorage class (most Python web frameworks do) to a denial of service potential. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-02 23:00 Message: Logged In: YES user_id=32974 FYI, I'd be happy to do the merging here if you wanted to give me checkin access. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-02 22:42 Message: Logged In: YES user_id=32974 An updated test_cgi.py is attached. I test both the readline behavior and add a test for basic multipart parsing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 23:48 Message: Logged In: YES user_id=6380 Can I tweak you into uploading a unit test? ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-03-31 21:56 Message: Logged In: YES user_id=32974 Re: parse_multipart.. yes, it looks like there's no use fixing that as it just turns around and puts the line into a list.. it is vulnerable but just by virtue of its non-use of a tempfile, it appears doomed anyway for large requests. I don't know of anything that uses it. Good catch wrt boundary recognition bug, I'm uploading another patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 17:13 Message: Logged In: YES user_id=6380 Methinks that the fix isn't quite right: it would incorrectly recognize as a boundary a very long line starting with "--" followed by the appropriate random string at offset 2**16. This could probably be taken care of by adding a flag that is true initially and after that keeps track of whether the previous line ended in \n. Also, there's a call to fp.readline() in parse_multipart() that you didn't patch -- it wouldn't help because that code is saving the lines in a list anyway, but isn't that code vulnerable as well? Or is it not used? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 From noreply at sourceforge.net Thu Aug 10 19:44:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Aug 2006 10:44:23 -0700 Subject: [ python-Bugs-1112549 ] cgi.FieldStorage memory usage can spike in line-oriented ops Message-ID: Bugs item #1112549, was opened at 2005-01-30 08:40 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 >Status: Closed Resolution: Accepted Priority: 8 Submitted By: Chris McDonough (chrism) Assigned to: Guido van Rossum (gvanrossum) Summary: cgi.FieldStorage memory usage can spike in line-oriented ops Initial Comment: Various parts of cgi.FieldStorage call its "read_lines_to_outerboundary", "read_lines" and "skip_lines" methods. These methods use the "readline" method of the file object that represents an input stream. The input stream is typically data supplied by an untrusted source (such as a user uploading a file from a web browser). The input data is not required by the RFC 822/1521/1522/1867 specifications to contain any newline characters. For example, it is within the bounds of the specification to supply a a multipart/form-data input stream with a "file-data" part that consists of a 2GB string composed entirely of "x" characters (which happens to be something I did that led me to noticing this bug). The simplest fix is to make use of the "size" argument of the readline method of the file object where it is used within all parts of FieldStorage that make use of it. A patch against the Python 2.3.4 cgi.py module that does this is attached. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-10 13:44 Message: Logged In: YES user_id=6380 Checked in as r51190 (Chris's patch plus a warning added to an XXX comment for parse_multipart()) and r51191 (Misc/NEWS). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-10 10:24 Message: Logged In: YES user_id=6380 OK, let's forget about parse_multipart(). Feel free to add a doc patch and a comment that deprecate it (actual warnings are not a good idea IMO). ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-08-10 07:08 Message: Logged In: YES user_id=32974 wrt parse_multipart: this function just turns around and puts the output from readline() into a list, as opposed to FieldStorage, which writes its chunked output to a tempfile, so just adding an argument to readline within it would not be useful. We'd only be able to fix the memory consumption issue in parse_multipart if we were to make it also use a tempfile, but it's not clear that *not* writing a tempfile isn't its expected behavior as the docs for parse_multipart state: Returns a dictionary just like parse_qs() keys are the field names, each value is a list of values for that field. This is easy to use but not much good if you are expecting megabytes to be uploaded -- in that case, use the FieldStorage class instead which is much more flexible. Is it OK to write a tempfile in this function (e.g. does that make it not useful on stuff like embedded systems)? If not, maybe we should just deprecate parse_multipart? I do find things that use it if I google hard enough but there are only 187 hits when I google for "cgi.parse_multipart" and 53,600 hits when I google for "cgi.FieldStorage". I'm uploading another file with your style change suggestions. It bundles all fixes to cgi.py, test_cgi.py, and test_cgi and includes the style changes, but does nothing about parse_multipart. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-09 18:23 Message: Logged In: YES user_id=6380 BTW it would be better if all patches were in a single file -- then you can delete the older patches (if SF lets you do that). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-09 17:58 Message: Logged In: YES user_id=6380 +1. minor nits: in the main patch: instead of + if line.endswith('\n'): + last_line_lfend = True + else: + last_line_lfend = False you can just use last_line_lfend = line.endswith('\n') in the unit test: instead of if type(a) != type(0): use if not isinstance(a, int): so that if some future release changes file.closed to return a bool (as it should :-) this test won't break. Is tehre a reason why you're not patching the fp.readline() call in parse_multipart()? It would seem to have the same issue (even if it isn't used in Zope :-). ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-08-07 13:51 Message: Logged In: YES user_id=32974 Yup, test/output/test_cgi did need fixing. Apologies, I did not understand the test regime. A new patch file named test_output_test_cgi- svn-50879.patch has been uploaded with the required change. regrtest.py now passes. As far as verify vs. vereq, the test_cgi module uses verify all over the place. I'm apt to not change all of those places, so to change it in just that one place is probably ineffective. Same for type comparison vs. isinstance. I'm trying to make the smallest change possible as opposed to refactoring the test module. I've uploaded a patch which contains a) the fix to cgi.py, b) the fix to test_cgi.py, and the fix to output/test_cgi. The stylistic change wrt to last_line_lfend is fine with me, but I'll leave that jugment to someone else. I'm not sure how to ensure the fix doesn't create other problems other than what has already been done by proving it still passes the tests it was subjected to in the "old" test suite and adds new tests that prove it no longer has the denial of service problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-07 01:50 Message: Logged In: YES user_id=33168 Doesn't this require a change to test/output/test_cgi or something like that? Does this test pass when run under regrtest.py ? The verify(x == y) should be vereq(x, y). type(a) != type(0), should be not isinstance(a, int). The last chunk of the patch in cgi.py should be: last_line_lfend = line.endswith('\n') rather than the 4 lines of if/else. I don't know if this patch really addresses the problem or creates other problems. However, if someone more knowledgable is confident about this patch, I'm fine with this going in. At this point, it might be better to wait for 2.5.1 though. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-07-27 17:42 Message: Logged In: YES user_id=32974 The files I've just uploaded are revisions to the cgi and test_cgi modules for the current state of the SVN trunk. If someone could apply these, it would be appreciated, or give me access and I'll be happy to. FTR, this is a bug which exposes systems which use the cgi.FieldStorage class (most Python web frameworks do) to a denial of service potential. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-02 23:00 Message: Logged In: YES user_id=32974 FYI, I'd be happy to do the merging here if you wanted to give me checkin access. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-02 22:42 Message: Logged In: YES user_id=32974 An updated test_cgi.py is attached. I test both the readline behavior and add a test for basic multipart parsing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 23:48 Message: Logged In: YES user_id=6380 Can I tweak you into uploading a unit test? ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-03-31 21:56 Message: Logged In: YES user_id=32974 Re: parse_multipart.. yes, it looks like there's no use fixing that as it just turns around and puts the line into a list.. it is vulnerable but just by virtue of its non-use of a tempfile, it appears doomed anyway for large requests. I don't know of anything that uses it. Good catch wrt boundary recognition bug, I'm uploading another patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 17:13 Message: Logged In: YES user_id=6380 Methinks that the fix isn't quite right: it would incorrectly recognize as a boundary a very long line starting with "--" followed by the appropriate random string at offset 2**16. This could probably be taken care of by adding a flag that is true initially and after that keeps track of whether the previous line ended in \n. Also, there's a call to fp.readline() in parse_multipart() that you didn't patch -- it wouldn't help because that code is saving the lines in a list anyway, but isn't that code vulnerable as well? Or is it not used? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 From noreply at sourceforge.net Thu Aug 10 19:46:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Aug 2006 10:46:09 -0700 Subject: [ python-Bugs-1112549 ] cgi.FieldStorage memory usage can spike in line-oriented ops Message-ID: Bugs item #1112549, was opened at 2005-01-30 13:40 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 8 Submitted By: Chris McDonough (chrism) Assigned to: Guido van Rossum (gvanrossum) Summary: cgi.FieldStorage memory usage can spike in line-oriented ops Initial Comment: Various parts of cgi.FieldStorage call its "read_lines_to_outerboundary", "read_lines" and "skip_lines" methods. These methods use the "readline" method of the file object that represents an input stream. The input stream is typically data supplied by an untrusted source (such as a user uploading a file from a web browser). The input data is not required by the RFC 822/1521/1522/1867 specifications to contain any newline characters. For example, it is within the bounds of the specification to supply a a multipart/form-data input stream with a "file-data" part that consists of a 2GB string composed entirely of "x" characters (which happens to be something I did that led me to noticing this bug). The simplest fix is to make use of the "size" argument of the readline method of the file object where it is used within all parts of FieldStorage that make use of it. A patch against the Python 2.3.4 cgi.py module that does this is attached. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-10 17:46 Message: Logged In: YES user_id=849994 Is this a backportable fix? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-10 17:44 Message: Logged In: YES user_id=6380 Checked in as r51190 (Chris's patch plus a warning added to an XXX comment for parse_multipart()) and r51191 (Misc/NEWS). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-10 14:24 Message: Logged In: YES user_id=6380 OK, let's forget about parse_multipart(). Feel free to add a doc patch and a comment that deprecate it (actual warnings are not a good idea IMO). ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-08-10 11:08 Message: Logged In: YES user_id=32974 wrt parse_multipart: this function just turns around and puts the output from readline() into a list, as opposed to FieldStorage, which writes its chunked output to a tempfile, so just adding an argument to readline within it would not be useful. We'd only be able to fix the memory consumption issue in parse_multipart if we were to make it also use a tempfile, but it's not clear that *not* writing a tempfile isn't its expected behavior as the docs for parse_multipart state: Returns a dictionary just like parse_qs() keys are the field names, each value is a list of values for that field. This is easy to use but not much good if you are expecting megabytes to be uploaded -- in that case, use the FieldStorage class instead which is much more flexible. Is it OK to write a tempfile in this function (e.g. does that make it not useful on stuff like embedded systems)? If not, maybe we should just deprecate parse_multipart? I do find things that use it if I google hard enough but there are only 187 hits when I google for "cgi.parse_multipart" and 53,600 hits when I google for "cgi.FieldStorage". I'm uploading another file with your style change suggestions. It bundles all fixes to cgi.py, test_cgi.py, and test_cgi and includes the style changes, but does nothing about parse_multipart. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-09 22:23 Message: Logged In: YES user_id=6380 BTW it would be better if all patches were in a single file -- then you can delete the older patches (if SF lets you do that). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-09 21:58 Message: Logged In: YES user_id=6380 +1. minor nits: in the main patch: instead of + if line.endswith('\n'): + last_line_lfend = True + else: + last_line_lfend = False you can just use last_line_lfend = line.endswith('\n') in the unit test: instead of if type(a) != type(0): use if not isinstance(a, int): so that if some future release changes file.closed to return a bool (as it should :-) this test won't break. Is tehre a reason why you're not patching the fp.readline() call in parse_multipart()? It would seem to have the same issue (even if it isn't used in Zope :-). ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-08-07 17:51 Message: Logged In: YES user_id=32974 Yup, test/output/test_cgi did need fixing. Apologies, I did not understand the test regime. A new patch file named test_output_test_cgi- svn-50879.patch has been uploaded with the required change. regrtest.py now passes. As far as verify vs. vereq, the test_cgi module uses verify all over the place. I'm apt to not change all of those places, so to change it in just that one place is probably ineffective. Same for type comparison vs. isinstance. I'm trying to make the smallest change possible as opposed to refactoring the test module. I've uploaded a patch which contains a) the fix to cgi.py, b) the fix to test_cgi.py, and the fix to output/test_cgi. The stylistic change wrt to last_line_lfend is fine with me, but I'll leave that jugment to someone else. I'm not sure how to ensure the fix doesn't create other problems other than what has already been done by proving it still passes the tests it was subjected to in the "old" test suite and adds new tests that prove it no longer has the denial of service problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-07 05:50 Message: Logged In: YES user_id=33168 Doesn't this require a change to test/output/test_cgi or something like that? Does this test pass when run under regrtest.py ? The verify(x == y) should be vereq(x, y). type(a) != type(0), should be not isinstance(a, int). The last chunk of the patch in cgi.py should be: last_line_lfend = line.endswith('\n') rather than the 4 lines of if/else. I don't know if this patch really addresses the problem or creates other problems. However, if someone more knowledgable is confident about this patch, I'm fine with this going in. At this point, it might be better to wait for 2.5.1 though. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-07-27 21:42 Message: Logged In: YES user_id=32974 The files I've just uploaded are revisions to the cgi and test_cgi modules for the current state of the SVN trunk. If someone could apply these, it would be appreciated, or give me access and I'll be happy to. FTR, this is a bug which exposes systems which use the cgi.FieldStorage class (most Python web frameworks do) to a denial of service potential. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-03 04:00 Message: Logged In: YES user_id=32974 FYI, I'd be happy to do the merging here if you wanted to give me checkin access. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-03 03:42 Message: Logged In: YES user_id=32974 An updated test_cgi.py is attached. I test both the readline behavior and add a test for basic multipart parsing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-04-01 04:48 Message: Logged In: YES user_id=6380 Can I tweak you into uploading a unit test? ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-01 02:56 Message: Logged In: YES user_id=32974 Re: parse_multipart.. yes, it looks like there's no use fixing that as it just turns around and puts the line into a list.. it is vulnerable but just by virtue of its non-use of a tempfile, it appears doomed anyway for large requests. I don't know of anything that uses it. Good catch wrt boundary recognition bug, I'm uploading another patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 22:13 Message: Logged In: YES user_id=6380 Methinks that the fix isn't quite right: it would incorrectly recognize as a boundary a very long line starting with "--" followed by the appropriate random string at offset 2**16. This could probably be taken care of by adding a flag that is true initially and after that keeps track of whether the previous line ended in \n. Also, there's a call to fp.readline() in parse_multipart() that you didn't patch -- it wouldn't help because that code is saving the lines in a list anyway, but isn't that code vulnerable as well? Or is it not used? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 From noreply at sourceforge.net Thu Aug 10 20:12:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Aug 2006 11:12:15 -0700 Subject: [ python-Bugs-1112549 ] cgi.FieldStorage memory usage can spike in line-oriented ops Message-ID: Bugs item #1112549, was opened at 2005-01-30 05:40 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Closed Resolution: Accepted Priority: 8 Submitted By: Chris McDonough (chrism) Assigned to: Guido van Rossum (gvanrossum) Summary: cgi.FieldStorage memory usage can spike in line-oriented ops Initial Comment: Various parts of cgi.FieldStorage call its "read_lines_to_outerboundary", "read_lines" and "skip_lines" methods. These methods use the "readline" method of the file object that represents an input stream. The input stream is typically data supplied by an untrusted source (such as a user uploading a file from a web browser). The input data is not required by the RFC 822/1521/1522/1867 specifications to contain any newline characters. For example, it is within the bounds of the specification to supply a a multipart/form-data input stream with a "file-data" part that consists of a 2GB string composed entirely of "x" characters (which happens to be something I did that led me to noticing this bug). The simplest fix is to make use of the "size" argument of the readline method of the file object where it is used within all parts of FieldStorage that make use of it. A patch against the Python 2.3.4 cgi.py module that does this is attached. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-10 11:12 Message: Logged In: YES user_id=33168 Yes, I believe so. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-10 10:46 Message: Logged In: YES user_id=849994 Is this a backportable fix? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-10 10:44 Message: Logged In: YES user_id=6380 Checked in as r51190 (Chris's patch plus a warning added to an XXX comment for parse_multipart()) and r51191 (Misc/NEWS). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-10 07:24 Message: Logged In: YES user_id=6380 OK, let's forget about parse_multipart(). Feel free to add a doc patch and a comment that deprecate it (actual warnings are not a good idea IMO). ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-08-10 04:08 Message: Logged In: YES user_id=32974 wrt parse_multipart: this function just turns around and puts the output from readline() into a list, as opposed to FieldStorage, which writes its chunked output to a tempfile, so just adding an argument to readline within it would not be useful. We'd only be able to fix the memory consumption issue in parse_multipart if we were to make it also use a tempfile, but it's not clear that *not* writing a tempfile isn't its expected behavior as the docs for parse_multipart state: Returns a dictionary just like parse_qs() keys are the field names, each value is a list of values for that field. This is easy to use but not much good if you are expecting megabytes to be uploaded -- in that case, use the FieldStorage class instead which is much more flexible. Is it OK to write a tempfile in this function (e.g. does that make it not useful on stuff like embedded systems)? If not, maybe we should just deprecate parse_multipart? I do find things that use it if I google hard enough but there are only 187 hits when I google for "cgi.parse_multipart" and 53,600 hits when I google for "cgi.FieldStorage". I'm uploading another file with your style change suggestions. It bundles all fixes to cgi.py, test_cgi.py, and test_cgi and includes the style changes, but does nothing about parse_multipart. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-09 15:23 Message: Logged In: YES user_id=6380 BTW it would be better if all patches were in a single file -- then you can delete the older patches (if SF lets you do that). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-09 14:58 Message: Logged In: YES user_id=6380 +1. minor nits: in the main patch: instead of + if line.endswith('\n'): + last_line_lfend = True + else: + last_line_lfend = False you can just use last_line_lfend = line.endswith('\n') in the unit test: instead of if type(a) != type(0): use if not isinstance(a, int): so that if some future release changes file.closed to return a bool (as it should :-) this test won't break. Is tehre a reason why you're not patching the fp.readline() call in parse_multipart()? It would seem to have the same issue (even if it isn't used in Zope :-). ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-08-07 10:51 Message: Logged In: YES user_id=32974 Yup, test/output/test_cgi did need fixing. Apologies, I did not understand the test regime. A new patch file named test_output_test_cgi- svn-50879.patch has been uploaded with the required change. regrtest.py now passes. As far as verify vs. vereq, the test_cgi module uses verify all over the place. I'm apt to not change all of those places, so to change it in just that one place is probably ineffective. Same for type comparison vs. isinstance. I'm trying to make the smallest change possible as opposed to refactoring the test module. I've uploaded a patch which contains a) the fix to cgi.py, b) the fix to test_cgi.py, and the fix to output/test_cgi. The stylistic change wrt to last_line_lfend is fine with me, but I'll leave that jugment to someone else. I'm not sure how to ensure the fix doesn't create other problems other than what has already been done by proving it still passes the tests it was subjected to in the "old" test suite and adds new tests that prove it no longer has the denial of service problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-06 22:50 Message: Logged In: YES user_id=33168 Doesn't this require a change to test/output/test_cgi or something like that? Does this test pass when run under regrtest.py ? The verify(x == y) should be vereq(x, y). type(a) != type(0), should be not isinstance(a, int). The last chunk of the patch in cgi.py should be: last_line_lfend = line.endswith('\n') rather than the 4 lines of if/else. I don't know if this patch really addresses the problem or creates other problems. However, if someone more knowledgable is confident about this patch, I'm fine with this going in. At this point, it might be better to wait for 2.5.1 though. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2006-07-27 14:42 Message: Logged In: YES user_id=32974 The files I've just uploaded are revisions to the cgi and test_cgi modules for the current state of the SVN trunk. If someone could apply these, it would be appreciated, or give me access and I'll be happy to. FTR, this is a bug which exposes systems which use the cgi.FieldStorage class (most Python web frameworks do) to a denial of service potential. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-02 20:00 Message: Logged In: YES user_id=32974 FYI, I'd be happy to do the merging here if you wanted to give me checkin access. ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-04-02 19:42 Message: Logged In: YES user_id=32974 An updated test_cgi.py is attached. I test both the readline behavior and add a test for basic multipart parsing. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 20:48 Message: Logged In: YES user_id=6380 Can I tweak you into uploading a unit test? ---------------------------------------------------------------------- Comment By: Chris McDonough (chrism) Date: 2005-03-31 18:56 Message: Logged In: YES user_id=32974 Re: parse_multipart.. yes, it looks like there's no use fixing that as it just turns around and puts the line into a list.. it is vulnerable but just by virtue of its non-use of a tempfile, it appears doomed anyway for large requests. I don't know of anything that uses it. Good catch wrt boundary recognition bug, I'm uploading another patch. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-03-31 14:13 Message: Logged In: YES user_id=6380 Methinks that the fix isn't quite right: it would incorrectly recognize as a boundary a very long line starting with "--" followed by the appropriate random string at offset 2**16. This could probably be taken care of by adding a flag that is true initially and after that keeps track of whether the previous line ended in \n. Also, there's a call to fp.readline() in parse_multipart() that you didn't patch -- it wouldn't help because that code is saving the lines in a list anyway, but isn't that code vulnerable as well? Or is it not used? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1112549&group_id=5470 From noreply at sourceforge.net Thu Aug 10 22:40:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Aug 2006 13:40:53 -0700 Subject: [ python-Feature Requests-1031288 ] Update unicodedata to version 4.0.1 Message-ID: Feature Requests item #1031288, was opened at 2004-09-20 15:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1031288&group_id=5470 Please note that this 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: Oliver Horn (ohorn) Assigned to: Nobody/Anonymous (nobody) Summary: Update unicodedata to version 4.0.1 Initial Comment: The unicodedata library (shipped with Python 2.3.4 and 2.4a3) is still version 3.2.0 albeit version 4.0.1 is available from unicode.org. Is it possible to update 4.0.1, at least for Python 2.4? ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-10 20:40 Message: Logged In: YES user_id=849994 unicodedata was updated to 4.1.0 for 2.5 while retaining 3.2.0 available. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2004-10-25 08:50 Message: Logged In: YES user_id=38388 While Python 2.4 is not possible anymore, we should consider this change for Python 2.5. I don't think we should stick to version 3.2 forever just because some RFC editors got their text wrong. Besides, changes to the Unicode database are usually backwards compatible for the vast majority of code points. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2004-10-23 11:54 Message: Logged In: YES user_id=21627 For Python 2.4, this is not possible, as the beta has already been published. For Python 2.5, it might be possible, but is difficult. Python relies on the unicodedata 3.2.0, as the IDNA RFCs mandate that Unicode 3.2 is used to implement IDNA. So any integration of 4.0.1 must a) still maintain access to the 3.2.0 data b) change all code that relies on 3.2.0 data to refer to these data explicitly c) not simply double the amount of data, but somehow allow for a differential representation. This is very difficult to implement, and hence hasn't been implemented for 2.4 (and might not be implemented for 2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1031288&group_id=5470 From noreply at sourceforge.net Fri Aug 11 00:55:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Aug 2006 15:55:36 -0700 Subject: [ python-Bugs-1069160 ] PyThreadState_SetAsyncExc segfault Message-ID: Bugs item #1069160, was opened at 2004-11-18 20:48 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 Please note that this 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: None Priority: 6 Submitted By: Tim Peters (tim_one) Assigned to: Guido van Rossum (gvanrossum) Summary: PyThreadState_SetAsyncExc segfault Initial Comment: PyThreadState_SetAsyncExc() crawls over the list of tstates without holding a mutex. Python implementation code has tried to get away with this kind of thing before (& more than once : and segfaults are always eventually reported. A common cause is that PyThreadState_DeleteCurrent() is typically called *without* the GIL held, so any thread can try to delete its own tstate *while* PyThreadState_SetAsyncExc() is trying to muck with that tstate. That the GIL is held by PyThreadState_SetAsyncExc's caller is no protection. Instead the code has to serialize against tstate chain mutations by acquiring head_mutex for the duration. Of course this is rare and can be virtually impossible to reproduce, but that makes the bug worse, not "better". ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-08-10 18:55 Message: Logged In: YES user_id=31435 For Python 2.5 (rev 51195), I changed the code as suggested in my 2005-02-06 comment; changed the docs to say the return value is always 0 or 1; and added a (ctypes-based) test case to test_threading.py. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-07 21:27 Message: Logged In: YES user_id=31435 Backport: sure, why not. Just don't ask anyone to test it . ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-07 21:19 Message: Logged In: YES user_id=80475 Should the head lock's be backported to Py2.4? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-07 21:08 Message: Logged In: YES user_id=6380 OK, to prevent further waste of time I've checked in the proposed fix. I have no idea what the count>1 comment was referring to any more; I'm sure I wrote it though. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-07 15:24 Message: Logged In: YES user_id=31435 So we're peeing away time on a Mystery Function with no known actual uses in the entire world. Cool . ---------------------------------------------------------------------- Comment By: Alex Martelli (aleax) Date: 2005-02-07 15:11 Message: Logged In: YES user_id=60314 I've checked the current codebase of the client for whom I originally wrote code using PyThreadState_SetAsyncExc, and that code is not currently used in production. It did that call while holding the GIL, FWIW. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-07 14:17 Message: Logged In: YES user_id=92689 To be honest: I don't yet have any code that relies on the feature, so there's nothing to break. Don't know about Alex, I'll ask him. I did a quick test (through ctypes), and the function works well with and without patch. I've attached the test script; it's mostly due to Peter Hansen: http://groups-beta.google.com/group/comp.lang.python/msg/ d310502f7c7133a9 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-07 10:41 Message: Logged In: YES user_id=31435 Just, this function isn't called anywhere in the Python distribution, so Armin and Guido and I have no certain way to know that it doesn't break the feature completely. The presumption here is that you do have code that uses this feature. If so, we're just asking that you verify your code still works after applying the patch. OTOH, if you don't have any code that uses this function, then there's no reason for you to get sucked into this. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-07 06:27 Message: Logged In: YES user_id=4771 I didn't worry too much about ZAP deadlocks precisely because this problem was already there elsewhere. I guess that if this is a problem, it should be discussed and fixed in another bug report, after we apply the obvious two-liner patch of the current tracker. ---------------------------------------------------------------------- Comment By: Just van Rossum (jvr) Date: 2005-02-07 04:04 Message: Logged In: YES user_id=92689 I'm not able to judge the patch. I'm only the one who had the feature request (together with Alex Martelli), but I know next to nothing about the implementation and all the subtle details. If you need a volunteer to apply a patch, sure, I'll gladly help, but the discussion is way over my head here. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-06 20:51 Message: Logged In: YES user_id=31435 It's already documented that PyThreadState_SetAsyncExc() must be called with the GIL held. head_mutex is only used to protect traversal/mutation of the threadstate chain, so is only held internally by functions that create, or destroy, thread states or interpreter states. It's certainly possible to get a deadlock then after the patch, not due to the GIL, but due to head_mutex alone. I doubt that any __del__ method would create/destroy thread/interpreter states on its own, the bigger danger is that once a __del__ method is invoked, other threads can run too, and they may do anything (including calling PyThreadState_SetAsyncExc() again! that seem the most likely way to deadlock). It would be good to have a clue about "I have no idea why this function warns about return values greater than 1". If in fact it should be impossible to have a count greater than 1 given that concurrent mutations to the tstate chain are locked out after the patch, then the patch could be rewritten to release head_mutex when it found p->thread_id == id the first time, before the ZAP. After the ZAP, the function would just return: if (p->thread_id == id) { PyObject *temp = p->async_exc; Py_XINCREF(exc); p->async_exc = exc; HEAD_UNLOCK(); Py_XDECREF(temp); return 1; } Then deadlock couldn't occur. I should note that PyInterpreterState_Clear() is prone to the same kind of deadlocks on head_mutex (it calls PyThreadState_Clear() with head_mutex held, and the latter does a lot of ZAPping). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2005-02-06 19:44 Message: Logged In: YES user_id=6380 But it was Just's idea, so assigning to him. Q for Just: would applying the patch cause any problems in your code that's using this feature? (Q. for Tim: hoes does the head_mutex in this file relate to the GIL? The ZAP() call would seem to require that the GIL is already head when this fn. is called, because it could invoke arbitrary Python __del__ code. Is there any other call that could acquire these locks in the opposite order, causing deadlocks?) ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-02-03 11:41 Message: Logged In: YES user_id=31435 Yup, that patch is all I had in mind. It's a shame that nobody cares enough about this function to test it (which isn't a dig at you, Armin -- I don't care enough either <0.5 wink>). BTW, I have no idea why this function warns about return values greater than 1. It's possible that the original author realized the tstate chain could mutate while the loop was running, and that's where "greater than 1" came from. If so, locking head_mutex should make that impossible ... OK, some quality time with CVS shows that Guido checked this function in, so assigning the report to him. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-02-02 06:19 Message: Logged In: YES user_id=4771 I guess that the patch you have in mind is just to protect the loop with HEAD_LOCK/HEAD_UNLOCK. I cannot test this patch (attached), though, as I don't have any code that uses this function. I can only tell that it also looks like a reasonable thing to do to me. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2004-11-19 10:32 Message: Logged In: YES user_id=31435 Changed Category to Threads. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1069160&group_id=5470 From noreply at sourceforge.net Fri Aug 11 04:20:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Aug 2006 19:20:25 -0700 Subject: [ python-Bugs-1529655 ] BROWSER path with capital letters Message-ID: <200608110220.k7B2KPqb023713@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1529655, was opened at 2006-07-27 05:55 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529655&group_id=5470 Please note that this 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: Ken McGaugh (kenmcgaugh) Assigned to: Nobody/Anonymous (nobody) Summary: BROWSER path with capital letters Initial Comment: If you set the BROWSER environment variable to a path that has capital letters in it, the webbrowser module will not work. This is python 2.4.1 under Fedora Core 4 linux. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2006-08-10 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-27 08:07 Message: Logged In: YES user_id=849994 webbrowser was almost completely rewritten in 2.5. I guess that problem will go away then. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1529655&group_id=5470 From noreply at sourceforge.net Fri Aug 11 06:22:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Aug 2006 21:22:00 -0700 Subject: [ python-Bugs-1534630 ] Python 2.5 svn crash in _elementtree.c Message-ID: Bugs item #1534630, was opened at 2006-08-04 08:29 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None >Priority: 8 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fredrik Lundh (effbot) Summary: Python 2.5 svn crash in _elementtree.c Initial Comment: /F's sourceforge screen scraper tool triggered a crash in _elementtree.c in the latest Python 2.5 svn. It seems that a Py_DECREF should probably be a Py_XDECREF unless there's some other logic bug I'm missing. Here's the patch if it's the former. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-10 21:21 Message: Logged In: YES user_id=33168 I don't think this patch will address the underlying problem. There are many DECREFs (and no XDECREFs) of last->text. It seems that the code believes there cannot be a NULL. Perhaps all the DECREFs of last->text should be XDECREF? I would really like this to get done for 2.5, but it shouldn't block release. Dropping priority. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&group_id=5470 From noreply at sourceforge.net Fri Aug 11 06:27:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Aug 2006 21:27:52 -0700 Subject: [ python-Bugs-1530559 ] struct.pack raises TypeError where it used to convert Message-ID: Bugs item #1530559, was opened at 2006-07-28 11:07 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Joe Wreschnig (piman) Assigned to: Bob Ippolito (etrepum) Summary: struct.pack raises TypeError where it used to convert Initial Comment: piman at toybox:~$ python2.4 -c "import struct; struct.pack('>H', 1.0)" piman at toybox:~$ python2.5 -c "import struct; struct.pack('>H', 1.0)" Traceback (most recent call last): File "", line 1, in File "/usr/lib/python2.5/struct.py", line 63, in pack return o.pack(*args) TypeError: unsupported operand type(s) for &: 'float' and 'long' This might have appeared as part of the struct optimizations; if struct isn't going to convert anymore for performance reasons, I think this should be mentioned in the release notes. Though personally I would prefer struct go back to converting its arguments. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-10 21:27 Message: Logged In: YES user_id=33168 This patch (or some variant) was checked in as 51119 ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-08-02 19:10 Message: Logged In: YES user_id=139309 I've attached a patch which should resolve this issue. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-28 20:21 Message: Logged In: YES user_id=33168 I'd like to see a deprecation warning so old code continues to work. struct is way to loose and needs to be tightened up, but that might not fully happen until py3k. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-28 12:44 Message: Logged In: YES user_id=849994 I think that's a question for python-dev. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-07-28 12:31 Message: Logged In: YES user_id=139309 That wasn't really intentional, but the old behavior looks a bit suspect: $ python2.4 -c "import struct; print repr(struct.pack('>H', 1.6))" '\x00\x01' We could change it to check for floats and do a DeprecationWarning? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-28 11:51 Message: Logged In: YES user_id=849994 Bob? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530559&group_id=5470 From noreply at sourceforge.net Fri Aug 11 06:44:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Aug 2006 21:44:55 -0700 Subject: [ python-Bugs-1538445 ] indent changes when copying command Message-ID: Bugs item #1538445, was opened at 2006-08-10 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=1538445&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Submitted By: mjd__ (mjd__) Assigned to: Nobody/Anonymous (nobody) Summary: indent changes when copying command Initial Comment: When copying a previous command by moving the cursor to the command and pressing 'enter', the indentation of the command is changed. The attached file is a saved session from the IDLE shell. mjd__/at/users/dot/sourceforge/dot/net ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1538445&group_id=5470 From noreply at sourceforge.net Fri Aug 11 07:06:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 10 Aug 2006 22:06:01 -0700 Subject: [ python-Bugs-1537167 ] 2nd issue with need for speed patch Message-ID: Bugs item #1537167, was opened at 2006-08-09 07:01 Message generated for change (Comment added) made by robinbryce2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537167&group_id=5470 Please note that this 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: Robin Bryce (robinbryce2) Assigned to: Phillip J. Eby (pje) Summary: 2nd issue with need for speed patch Initial Comment: This is not a duplicate of the "realease manager pronouncement on 302 Fix needed" issue raised on pydev. If a custom importer is present, import.c skips the builtin import machinery if the find_module method of that importer returns None. For python 2.4.3 if find_module returns none the normal builtin machinery gets a lookin. The relevent change was the addition of a continue statement with svn commit r46372 (at around line 1283 of import.c on the trunk). I don't understand, in the face of this change, how pep 302 importers are expected to cascade. returning None from find_module is the way an importer says "no I can't load this module but I cant say for certain this means ImportError" isnt it ? One (unintended?) consequence of this change is the following corner case: As __import__ allows non dotted module names __import__('fakemod.a/b') *will* succede on python 2.4.3 provided b is a directory under the package a that contains an __init__.py. In python 2.5b3 this fails. I've atatched a detailed repro case of this particular corner case. ---------------------------------------------------------------------- >Comment By: Robin Bryce (robinbryce2) Date: 2006-08-11 06:06 Message: Logged In: YES user_id=1547259 >It never was the intention of the entire machinery that such >a fallback is implemented. Ah. And having just reread pep 302 the wording on this is actualy quite specifif. From: "specification part 1: the importer protocol" "It should return a loader object if the module was found". Wich precludes the trickery I was thinking of anyway. Appologies for the bandwidth this has taken up. I have no objection to this bug being closed. Thanks for your time. Cheers, Robin ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-10 00:33 Message: Logged In: YES user_id=21627 The patch is originally mine; it does not have to do much with the need-for-speed sprint. The rationale is to reduce the number of stat/open calls when loading a module and the directory doesn't even exist (e.g. for the first sys.path entry, which is python25.zip). It originally put True/False on sys.path_importer_cache. Philipp Eby changed it to put the NullImporter on path_importer_cache, and not fall back to the builtin import if the path importer returns None. It never was the intention of the entire machinery that such a fallback is implemented. Instead, it always should have continued with the next sys.path entry instead. If a path import claims responsibility for a sys.path entry, and then finds it cannot fulfill the responsibility, and wants to fall back to the traditional file-based lookup, it needs to implement that itself. I would advise against doing so, though, and make the path import reject responsibility for the sys.path entry in the first place if that entry really is an on-disk directory. ---------------------------------------------------------------------- Comment By: Robin Bryce (robinbryce2) Date: 2006-08-09 16:50 Message: Logged In: YES user_id=1547259 I've tried the attatched test case patch against release24-maint and it passes. ---------------------------------------------------------------------- Comment By: Robin Bryce (robinbryce2) Date: 2006-08-09 15:33 Message: Logged In: YES user_id=1547259 The 'illeagal' module name is a red herring. The problem exists with leagal paths also:: Python 2.5b3 (trunk:51136, Aug 9 2006, 15:17:14) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from fakemod import urlpathimport >>> urlpathimport.install() >>> m=__import__('fakemod.a') *** fullname='fakemod.a' initpath='fakemod' *** Traceback (most recent call last): File "", line 1, in ImportError: No module named a >>> robin at rsb2-ubuntu:~/devel/blackmile$ python Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from fakemod import urlpathimport >>> urlpathimport.install() >>> m=__import__('fakemod.a') *** fullname='fakemod.a' initpath='fakemod' *** >>> Working on a test case. At present I think it is imposible for a 2.5 custom importer to choose *not* to import a standard python module by returning None from find_module. Because if it returns None the standard import is skipped. gbrandl, I think it was your commit that added the 'continue' statement, what is the reasoning behind making that optimisation ? Cheers, Robin ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-09 14:28 Message: Logged In: YES user_id=849994 Guido agreed that the 2.4 behavior is to be regarded as a bug: http://mail.python.org/pipermail/python-dev/2006-May/065174.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-09 13:27 Message: Logged In: YES user_id=21627 I'd say it is a bug that Python 2.4 allows non-dotted module names for __import__. Can you come up with a change in behaviour for "regular" module names? As for cascading: path importers doe not cascade. Per sys.path item, there can be at most one path importer. They "cascade" in the sense that search continues with other sys.path items if it wasn't found in one sys.path entry. This cascading continues to work with 2.5. Phillip, can you take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537167&group_id=5470 From noreply at sourceforge.net Fri Aug 11 09:27:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Aug 2006 00:27:24 -0700 Subject: [ python-Bugs-1537167 ] 2nd issue with need for speed patch Message-ID: Bugs item #1537167, was opened at 2006-08-09 06:01 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537167&group_id=5470 Please note that this 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: Wont Fix Priority: 5 Submitted By: Robin Bryce (robinbryce2) Assigned to: Phillip J. Eby (pje) Summary: 2nd issue with need for speed patch Initial Comment: This is not a duplicate of the "realease manager pronouncement on 302 Fix needed" issue raised on pydev. If a custom importer is present, import.c skips the builtin import machinery if the find_module method of that importer returns None. For python 2.4.3 if find_module returns none the normal builtin machinery gets a lookin. The relevent change was the addition of a continue statement with svn commit r46372 (at around line 1283 of import.c on the trunk). I don't understand, in the face of this change, how pep 302 importers are expected to cascade. returning None from find_module is the way an importer says "no I can't load this module but I cant say for certain this means ImportError" isnt it ? One (unintended?) consequence of this change is the following corner case: As __import__ allows non dotted module names __import__('fakemod.a/b') *will* succede on python 2.4.3 provided b is a directory under the package a that contains an __init__.py. In python 2.5b3 this fails. I've atatched a detailed repro case of this particular corner case. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-11 07:27 Message: Logged In: YES user_id=849994 I've now added a note to the PEP explaining this behavior explicitly. Closing as Won't Fix. ---------------------------------------------------------------------- Comment By: Robin Bryce (robinbryce2) Date: 2006-08-11 05:06 Message: Logged In: YES user_id=1547259 >It never was the intention of the entire machinery that such >a fallback is implemented. Ah. And having just reread pep 302 the wording on this is actualy quite specifif. From: "specification part 1: the importer protocol" "It should return a loader object if the module was found". Wich precludes the trickery I was thinking of anyway. Appologies for the bandwidth this has taken up. I have no objection to this bug being closed. Thanks for your time. Cheers, Robin ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-09 23:33 Message: Logged In: YES user_id=21627 The patch is originally mine; it does not have to do much with the need-for-speed sprint. The rationale is to reduce the number of stat/open calls when loading a module and the directory doesn't even exist (e.g. for the first sys.path entry, which is python25.zip). It originally put True/False on sys.path_importer_cache. Philipp Eby changed it to put the NullImporter on path_importer_cache, and not fall back to the builtin import if the path importer returns None. It never was the intention of the entire machinery that such a fallback is implemented. Instead, it always should have continued with the next sys.path entry instead. If a path import claims responsibility for a sys.path entry, and then finds it cannot fulfill the responsibility, and wants to fall back to the traditional file-based lookup, it needs to implement that itself. I would advise against doing so, though, and make the path import reject responsibility for the sys.path entry in the first place if that entry really is an on-disk directory. ---------------------------------------------------------------------- Comment By: Robin Bryce (robinbryce2) Date: 2006-08-09 15:50 Message: Logged In: YES user_id=1547259 I've tried the attatched test case patch against release24-maint and it passes. ---------------------------------------------------------------------- Comment By: Robin Bryce (robinbryce2) Date: 2006-08-09 14:33 Message: Logged In: YES user_id=1547259 The 'illeagal' module name is a red herring. The problem exists with leagal paths also:: Python 2.5b3 (trunk:51136, Aug 9 2006, 15:17:14) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from fakemod import urlpathimport >>> urlpathimport.install() >>> m=__import__('fakemod.a') *** fullname='fakemod.a' initpath='fakemod' *** Traceback (most recent call last): File "", line 1, in ImportError: No module named a >>> robin at rsb2-ubuntu:~/devel/blackmile$ python Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from fakemod import urlpathimport >>> urlpathimport.install() >>> m=__import__('fakemod.a') *** fullname='fakemod.a' initpath='fakemod' *** >>> Working on a test case. At present I think it is imposible for a 2.5 custom importer to choose *not* to import a standard python module by returning None from find_module. Because if it returns None the standard import is skipped. gbrandl, I think it was your commit that added the 'continue' statement, what is the reasoning behind making that optimisation ? Cheers, Robin ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-09 13:28 Message: Logged In: YES user_id=849994 Guido agreed that the 2.4 behavior is to be regarded as a bug: http://mail.python.org/pipermail/python-dev/2006-May/065174.html ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-09 12:27 Message: Logged In: YES user_id=21627 I'd say it is a bug that Python 2.4 allows non-dotted module names for __import__. Can you come up with a change in behaviour for "regular" module names? As for cascading: path importers doe not cascade. Per sys.path item, there can be at most one path importer. They "cascade" in the sense that search continues with other sys.path items if it wasn't found in one sys.path entry. This cascading continues to work with 2.5. Phillip, can you take a look? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537167&group_id=5470 From noreply at sourceforge.net Fri Aug 11 10:10:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Aug 2006 01:10:32 -0700 Subject: [ python-Bugs-1528802 ] Turkish Character Message-ID: Bugs item #1528802, was opened at 2006-07-26 10:05 Message generated for change (Comment added) made by ahmetbiskinler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 Please note that this 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: 6 Submitted By: Ahmet Bi?kinler (ahmetbiskinler) Assigned to: M.-A. Lemburg (lemburg) Summary: Turkish Character Initial Comment: >>> print "May?s".upper() >>> MAY?S >>> import locale >>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254') >>> print "May?s".upper() >>> MAY?S >>> print "???i???".upper() >>> ???I??? MAY?S should be MAYIS ???I??? should be ??????I but >>> "May?s".upper() >>> "MAYIS" is right ---------------------------------------------------------------------- >Comment By: Ahmet Bi?kinler (ahmetbiskinler) Date: 2006-08-11 11:10 Message: Logged In: YES user_id=1481281 What happened? Is it solved? How is it going? What is the final step? ...? ...? Could you please give me some information about the bug please? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 From noreply at sourceforge.net Fri Aug 11 11:24:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Aug 2006 02:24:52 -0700 Subject: [ python-Bugs-1538556 ] PyThreadState_SetAsyncExc bug Message-ID: Bugs item #1538556, was opened at 2006-08-11 12:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1538556&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: ganges master (gangesmaster) Assigned to: Nobody/Anonymous (nobody) Summary: PyThreadState_SetAsyncExc bug Initial Comment: while working on a library for raising exceptions in the context of another thread, i've come across a bug in PyThreadState_SetAsyncExc. if i raise an instance, sys.exc_info() confuses the exception value for the exception type, and the exception value is set None. if i raise the type itself, the interpreter creates an instance internally, but then i can't pass arguments to the exception. see this post for more info http://mail.python.org/pipermail/python-dev/2006-August/068158.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1538556&group_id=5470 From noreply at sourceforge.net Fri Aug 11 14:42:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Aug 2006 05:42:07 -0700 Subject: [ python-Bugs-1534630 ] Python 2.5 svn crash in _elementtree.c Message-ID: Bugs item #1534630, was opened at 2006-08-04 11:29 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fredrik Lundh (effbot) Summary: Python 2.5 svn crash in _elementtree.c Initial Comment: /F's sourceforge screen scraper tool triggered a crash in _elementtree.c in the latest Python 2.5 svn. It seems that a Py_DECREF should probably be a Py_XDECREF unless there's some other logic bug I'm missing. Here's the patch if it's the former. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-11 08:42 Message: Logged In: YES user_id=12800 You might be right about the basic invariant problem, but why shouldn't it block release? Is your thinking that because it's a problem in an extension module (and a new and probably rarely used one at that)? It's definitely severe enough to hit people who use the module, not that it can't be fixed after the 2.5 release of course. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-11 00:21 Message: Logged In: YES user_id=33168 I don't think this patch will address the underlying problem. There are many DECREFs (and no XDECREFs) of last->text. It seems that the code believes there cannot be a NULL. Perhaps all the DECREFs of last->text should be XDECREF? I would really like this to get done for 2.5, but it shouldn't block release. Dropping priority. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&group_id=5470 From noreply at sourceforge.net Fri Aug 11 17:23:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Aug 2006 08:23:37 -0700 Subject: [ python-Bugs-1538778 ] pyo's are not overwritten by different optimization levels Message-ID: Bugs item #1538778, was opened at 2006-08-11 11:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1538778&group_id=5470 Please note that this 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: Toshio Kuratomi (abadger1999) Assigned to: Nobody/Anonymous (nobody) Summary: pyo's are not overwritten by different optimization levels Initial Comment: If I invoke "python -OO" on a set of files, python creates a set of .pyo files. If I then realize this is an incredibly stupid thing to do because it removes the docstrings from the output and this program requires those docstrings python does not give me a method of overwriting the generated .pyos. I anticipated that running "python -O" would detect that the already generated .pyos were created in a different optimixation level and overwrite them with new .pyos. Barring that, I expected there to be a command line switch to tell python to overwrite the previously generated .pyo cache files. Finding neither, I realized that the only way to recover docstrings for people using python -O was to rm all the generated .pyo files. This seems like a bug or a missing feature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1538778&group_id=5470 From noreply at sourceforge.net Fri Aug 11 17:30:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Aug 2006 08:30:30 -0700 Subject: [ python-Bugs-1534630 ] Python 2.5 svn crash in _elementtree.c Message-ID: Bugs item #1534630, was opened at 2006-08-04 08:29 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fredrik Lundh (effbot) Summary: Python 2.5 svn crash in _elementtree.c Initial Comment: /F's sourceforge screen scraper tool triggered a crash in _elementtree.c in the latest Python 2.5 svn. It seems that a Py_DECREF should probably be a Py_XDECREF unless there's some other logic bug I'm missing. Here's the patch if it's the former. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-11 08:30 Message: Logged In: YES user_id=33168 Yes, for all the reasons you mention. Also, I'm not sure that anyone other than /f can address this problem and I don't know when he will be able to fix it. I would very much prefer this be addressed prior to 2.5, but if it has to wait for 2.5.1 so be it. Also, I would guess this same problem is in the external version, so it's probably not a 'regression' either, even though this is a new module. Realize that there's still a month before release. So this is a non-issue if you can convince /f to fix it soon-ish. :-) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-11 05:42 Message: Logged In: YES user_id=12800 You might be right about the basic invariant problem, but why shouldn't it block release? Is your thinking that because it's a problem in an extension module (and a new and probably rarely used one at that)? It's definitely severe enough to hit people who use the module, not that it can't be fixed after the 2.5 release of course. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-10 21:21 Message: Logged In: YES user_id=33168 I don't think this patch will address the underlying problem. There are many DECREFs (and no XDECREFs) of last->text. It seems that the code believes there cannot be a NULL. Perhaps all the DECREFs of last->text should be XDECREF? I would really like this to get done for 2.5, but it shouldn't block release. Dropping priority. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&group_id=5470 From noreply at sourceforge.net Fri Aug 11 19:23:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 11 Aug 2006 10:23:07 -0700 Subject: [ python-Bugs-1534630 ] Python 2.5 svn crash in _elementtree.c Message-ID: Bugs item #1534630, was opened at 2006-08-04 17:29 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fredrik Lundh (effbot) Summary: Python 2.5 svn crash in _elementtree.c Initial Comment: /F's sourceforge screen scraper tool triggered a crash in _elementtree.c in the latest Python 2.5 svn. It seems that a Py_DECREF should probably be a Py_XDECREF unless there's some other logic bug I'm missing. Here's the patch if it's the former. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2006-08-11 19:23 Message: Logged In: YES user_id=38376 I'm pretty sure this only happens if you're explicitly using the TreeBuilder class, which is a rather specialized use of ET. I'm also pretty sure that this is a cElementTree regression; I have a vague memory that I did some "optimizations" around 1.0.4 or 1.0.5 that might have caused this. I hope to find some time to look at this this weekend. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-11 17:30 Message: Logged In: YES user_id=33168 Yes, for all the reasons you mention. Also, I'm not sure that anyone other than /f can address this problem and I don't know when he will be able to fix it. I would very much prefer this be addressed prior to 2.5, but if it has to wait for 2.5.1 so be it. Also, I would guess this same problem is in the external version, so it's probably not a 'regression' either, even though this is a new module. Realize that there's still a month before release. So this is a non-issue if you can convince /f to fix it soon-ish. :-) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-11 14:42 Message: Logged In: YES user_id=12800 You might be right about the basic invariant problem, but why shouldn't it block release? Is your thinking that because it's a problem in an extension module (and a new and probably rarely used one at that)? It's definitely severe enough to hit people who use the module, not that it can't be fixed after the 2.5 release of course. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-11 06:21 Message: Logged In: YES user_id=33168 I don't think this patch will address the underlying problem. There are many DECREFs (and no XDECREFs) of last->text. It seems that the code believes there cannot be a NULL. Perhaps all the DECREFs of last->text should be XDECREF? I would really like this to get done for 2.5, but it shouldn't block release. Dropping priority. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&group_id=5470 From noreply at sourceforge.net Sat Aug 12 13:31:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 04:31:23 -0700 Subject: [ python-Bugs-1377858 ] segfaults when using __del__ and weakrefs Message-ID: Bugs item #1377858, was opened at 2005-12-10 21:20 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Carl Friedrich Bolz (cfbolz) Assigned to: Michael Hudson (mwh) Summary: segfaults when using __del__ and weakrefs Initial Comment: You can segfault Python by creating a weakref to an object in its __del__ method, storing it somewhere and then trying to dereference the weakref afterwards. the attached file shows the described behaviour. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-08-12 11:31 Message: Logged In: YES user_id=4771 The clear_weakref(*list) only clears the first weakref to the object. You need a while loop in your patch. (attached proposed fix) Now we're left with fixing the same bug in old-style classes (surprize surprize), and turning the crasher into a test. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-29 17:36 Message: Logged In: YES user_id=357491 So after staring at this crasher it seemed to me to be that clearing the new weakrefs w/o calling their finalizers after calling the object's finalizer was the best solution. I couldn't think of any other good way to communicate to the new weakrefs that the object they refer to was no longer viable memory without doing clear_weakref() work by hand. Attached is a patch to do this. Michael, can you have a look? ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 19:29 Message: Logged In: YES user_id=1188172 Added to outstanding_crashes.py. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-01-09 11:58 Message: Logged In: YES user_id=6656 Hmm, maybe the referenced mayhem is more to do with clearing __dict__ than calling __del__. What breaks if we do things in this order: 1. call __del__ 2. clear weakrefs 3. clear __dict__ ? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-01-09 11:54 Message: Logged In: YES user_id=6656 Hmm, I was kind of hoping this report would get more attention. The problem is obvious if you read typeobject.c around line 660: the weakref list is cleared before __del__ is called, so any weakrefs added during the execution of __del__ are never informed of the object's death. One fix for this would be to clear the weakref list _after_ calling __del__ but that led to other mayhem in ways I haven't boethered to understand (see SF bug #742911). I guess we could just clear out any weakrefs created in __del__ without calling their callbacks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&group_id=5470 From noreply at sourceforge.net Sat Aug 12 21:28:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 12:28:51 -0700 Subject: [ python-Bugs-1539295 ] Long command lines don't work on Windows Message-ID: Bugs item #1539295, was opened at 2006-08-12 21:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this 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: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 From noreply at sourceforge.net Sat Aug 12 23:53:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 14:53:07 -0700 Subject: [ python-Bugs-1539295 ] Long command lines don't work on Windows Message-ID: Bugs item #1539295, was opened at 2006-08-12 12:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this 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: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 14:53 Message: Logged In: YES user_id=33168 Albert, could you try to work up a patch implementing this? It would be much more likely to get fixed that way. It should also work with older Windows (9x/ME). Cheers, n ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 From noreply at sourceforge.net Sat Aug 12 23:56:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 14:56:35 -0700 Subject: [ python-Bugs-1539295 ] Long command lines don't work on Windows Message-ID: Bugs item #1539295, was opened at 2006-08-12 21:28 Message generated for change (Comment added) made by albertstrasheim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this 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: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. ---------------------------------------------------------------------- >Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 23:56 Message: Logged In: YES user_id=945096 Okay, I'll see what I can do. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 23:53 Message: Logged In: YES user_id=33168 Albert, could you try to work up a patch implementing this? It would be much more likely to get fixed that way. It should also work with older Windows (9x/ME). Cheers, n ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 From noreply at sourceforge.net Sun Aug 13 00:30:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 15:30:42 -0700 Subject: [ python-Bugs-1539336 ] distutils example code missing imports Message-ID: Bugs item #1539336, was opened at 2006-08-13 00:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539336&group_id=5470 Please note that this 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: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: distutils example code missing imports Initial Comment: The example code in the "Single extension module" section of "Distributing Python Modules" is missing some imports. Both examples should import Extension in addition to setup. Otherwise, the following error results when the examples are executed: NameError: name 'Extension' is not defined There might be similar issues elsewhere in the documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539336&group_id=5470 From noreply at sourceforge.net Sun Aug 13 02:03:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 17:03:15 -0700 Subject: [ python-Bugs-1539295 ] Long command lines don't work on Windows Message-ID: Bugs item #1539295, was opened at 2006-08-12 21:28 Message generated for change (Comment added) made by albertstrasheim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this 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: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. ---------------------------------------------------------------------- >Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:03 Message: Logged In: YES user_id=945096 Attached a first try at a patch. Some things that could still be changed: - We might want to print a different log info message when using a temp file instead of calling the command directly - Restructure the code so that the spawnv call only appears in one place The setup.py I attached should allow anyone to duplicate this problem. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 23:56 Message: Logged In: YES user_id=945096 Okay, I'll see what I can do. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 23:53 Message: Logged In: YES user_id=33168 Albert, could you try to work up a patch implementing this? It would be much more likely to get fixed that way. It should also work with older Windows (9x/ME). Cheers, n ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 From noreply at sourceforge.net Sun Aug 13 02:09:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 17:09:56 -0700 Subject: [ python-Bugs-1539295 ] Long command lines don't work on Windows Message-ID: Bugs item #1539295, was opened at 2006-08-12 21:28 Message generated for change (Comment added) made by albertstrasheim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this 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: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. ---------------------------------------------------------------------- >Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:09 Message: Logged In: YES user_id=945096 Looks like the max length on Windows 95 might be as low as 256 characters, but I'm not sure about this. It seems Windows 98 and Windows Me have a limit of 2048 characters. SCons assumes 2048 characters on any Windows system, so I did the same. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:03 Message: Logged In: YES user_id=945096 Attached a first try at a patch. Some things that could still be changed: - We might want to print a different log info message when using a temp file instead of calling the command directly - Restructure the code so that the spawnv call only appears in one place The setup.py I attached should allow anyone to duplicate this problem. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 23:56 Message: Logged In: YES user_id=945096 Okay, I'll see what I can do. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 23:53 Message: Logged In: YES user_id=33168 Albert, could you try to work up a patch implementing this? It would be much more likely to get fixed that way. It should also work with older Windows (9x/ME). Cheers, n ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 From noreply at sourceforge.net Sun Aug 13 02:16:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 17:16:10 -0700 Subject: [ python-Bugs-1539295 ] Long command lines don't work on Windows Message-ID: Bugs item #1539295, was opened at 2006-08-12 12:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this 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: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 17:16 Message: Logged In: YES user_id=33168 Thanks for the patch! It looks pretty good, but there are a few changes (and additions) I would like to see. I don't understand why you use 2k in the patch, but mention the limit is 32k. You should use mkstemp() instead of mktemp(). That will open the file for you, so you can just do os.write(fd, data). You will need to close the file. I would prefer to see a single os.spawnv() call. You would need tmp defined (but possibly None) and in the finally, you would have to check if tmp: os.remove(). It would also be nice to see test and doc updates. The tests are in Lib/distutils/tests. Thanks again for the patch. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 17:09 Message: Logged In: YES user_id=945096 Looks like the max length on Windows 95 might be as low as 256 characters, but I'm not sure about this. It seems Windows 98 and Windows Me have a limit of 2048 characters. SCons assumes 2048 characters on any Windows system, so I did the same. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 17:03 Message: Logged In: YES user_id=945096 Attached a first try at a patch. Some things that could still be changed: - We might want to print a different log info message when using a temp file instead of calling the command directly - Restructure the code so that the spawnv call only appears in one place The setup.py I attached should allow anyone to duplicate this problem. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 14:56 Message: Logged In: YES user_id=945096 Okay, I'll see what I can do. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 14:53 Message: Logged In: YES user_id=33168 Albert, could you try to work up a patch implementing this? It would be much more likely to get fixed that way. It should also work with older Windows (9x/ME). Cheers, n ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 From noreply at sourceforge.net Sun Aug 13 02:17:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 17:17:09 -0700 Subject: [ python-Bugs-1539295 ] Long command lines don't work on Windows Message-ID: Bugs item #1539295, was opened at 2006-08-12 12:28 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this 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: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 17:17 Message: Logged In: YES user_id=33168 Ah, our msgs crossed. That explains the 2k. It would be nice to add a comment about that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 17:16 Message: Logged In: YES user_id=33168 Thanks for the patch! It looks pretty good, but there are a few changes (and additions) I would like to see. I don't understand why you use 2k in the patch, but mention the limit is 32k. You should use mkstemp() instead of mktemp(). That will open the file for you, so you can just do os.write(fd, data). You will need to close the file. I would prefer to see a single os.spawnv() call. You would need tmp defined (but possibly None) and in the finally, you would have to check if tmp: os.remove(). It would also be nice to see test and doc updates. The tests are in Lib/distutils/tests. Thanks again for the patch. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 17:09 Message: Logged In: YES user_id=945096 Looks like the max length on Windows 95 might be as low as 256 characters, but I'm not sure about this. It seems Windows 98 and Windows Me have a limit of 2048 characters. SCons assumes 2048 characters on any Windows system, so I did the same. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 17:03 Message: Logged In: YES user_id=945096 Attached a first try at a patch. Some things that could still be changed: - We might want to print a different log info message when using a temp file instead of calling the command directly - Restructure the code so that the spawnv call only appears in one place The setup.py I attached should allow anyone to duplicate this problem. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 14:56 Message: Logged In: YES user_id=945096 Okay, I'll see what I can do. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 14:53 Message: Logged In: YES user_id=33168 Albert, could you try to work up a patch implementing this? It would be much more likely to get fixed that way. It should also work with older Windows (9x/ME). Cheers, n ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 From noreply at sourceforge.net Sun Aug 13 02:21:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 17:21:32 -0700 Subject: [ python-Bugs-1539336 ] distutils example code missing imports Message-ID: Bugs item #1539336, was opened at 2006-08-12 15:30 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539336&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation >Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Albert Strasheim (albertstrasheim) >Assigned to: Neal Norwitz (nnorwitz) Summary: distutils example code missing imports Initial Comment: The example code in the "Single extension module" section of "Distributing Python Modules" is missing some imports. Both examples should import Extension in addition to setup. Otherwise, the following error results when the examples are executed: NameError: name 'Extension' is not defined There might be similar issues elsewhere in the documentation. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 17:21 Message: Logged In: YES user_id=33168 Thanks! Committed revision 51240. Let us know if you find other places in the doc that are wrong. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539336&group_id=5470 From noreply at sourceforge.net Sun Aug 13 02:44:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 17:44:52 -0700 Subject: [ python-Bugs-1539295 ] Long command lines don't work on Windows Message-ID: Bugs item #1539295, was opened at 2006-08-12 21:28 Message generated for change (Comment added) made by albertstrasheim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this 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: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. ---------------------------------------------------------------------- >Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:44 Message: Logged In: YES user_id=945096 Okay, I'm going to try to implement some of your suggestions. A comment at the top of spawn.py says: # This module should be kept compatible with Python 2.1. but mkstemp was only added in Python 2.3. Is this comment still valid? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-13 02:17 Message: Logged In: YES user_id=33168 Ah, our msgs crossed. That explains the 2k. It would be nice to add a comment about that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-13 02:16 Message: Logged In: YES user_id=33168 Thanks for the patch! It looks pretty good, but there are a few changes (and additions) I would like to see. I don't understand why you use 2k in the patch, but mention the limit is 32k. You should use mkstemp() instead of mktemp(). That will open the file for you, so you can just do os.write(fd, data). You will need to close the file. I would prefer to see a single os.spawnv() call. You would need tmp defined (but possibly None) and in the finally, you would have to check if tmp: os.remove(). It would also be nice to see test and doc updates. The tests are in Lib/distutils/tests. Thanks again for the patch. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:09 Message: Logged In: YES user_id=945096 Looks like the max length on Windows 95 might be as low as 256 characters, but I'm not sure about this. It seems Windows 98 and Windows Me have a limit of 2048 characters. SCons assumes 2048 characters on any Windows system, so I did the same. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:03 Message: Logged In: YES user_id=945096 Attached a first try at a patch. Some things that could still be changed: - We might want to print a different log info message when using a temp file instead of calling the command directly - Restructure the code so that the spawnv call only appears in one place The setup.py I attached should allow anyone to duplicate this problem. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 23:56 Message: Logged In: YES user_id=945096 Okay, I'll see what I can do. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 23:53 Message: Logged In: YES user_id=33168 Albert, could you try to work up a patch implementing this? It would be much more likely to get fixed that way. It should also work with older Windows (9x/ME). Cheers, n ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 From noreply at sourceforge.net Sun Aug 13 03:51:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 18:51:43 -0700 Subject: [ python-Bugs-1539295 ] Long command lines don't work on Windows Message-ID: Bugs item #1539295, was opened at 2006-08-12 21:28 Message generated for change (Comment added) made by albertstrasheim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this 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: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. ---------------------------------------------------------------------- >Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 03:51 Message: Logged In: YES user_id=945096 New patch. Included a test case that fails without the changes and passes with the changes. Modified the code to incorporate some of nnorwitz's suggestions, except for the mkstemp change. The test case has a minor bug: the output of the build is still created relative to the the current working directory. I don't know distutils very well, so I'm not quite sure which option to mangle to fix this. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:44 Message: Logged In: YES user_id=945096 Okay, I'm going to try to implement some of your suggestions. A comment at the top of spawn.py says: # This module should be kept compatible with Python 2.1. but mkstemp was only added in Python 2.3. Is this comment still valid? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-13 02:17 Message: Logged In: YES user_id=33168 Ah, our msgs crossed. That explains the 2k. It would be nice to add a comment about that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-13 02:16 Message: Logged In: YES user_id=33168 Thanks for the patch! It looks pretty good, but there are a few changes (and additions) I would like to see. I don't understand why you use 2k in the patch, but mention the limit is 32k. You should use mkstemp() instead of mktemp(). That will open the file for you, so you can just do os.write(fd, data). You will need to close the file. I would prefer to see a single os.spawnv() call. You would need tmp defined (but possibly None) and in the finally, you would have to check if tmp: os.remove(). It would also be nice to see test and doc updates. The tests are in Lib/distutils/tests. Thanks again for the patch. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:09 Message: Logged In: YES user_id=945096 Looks like the max length on Windows 95 might be as low as 256 characters, but I'm not sure about this. It seems Windows 98 and Windows Me have a limit of 2048 characters. SCons assumes 2048 characters on any Windows system, so I did the same. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:03 Message: Logged In: YES user_id=945096 Attached a first try at a patch. Some things that could still be changed: - We might want to print a different log info message when using a temp file instead of calling the command directly - Restructure the code so that the spawnv call only appears in one place The setup.py I attached should allow anyone to duplicate this problem. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 23:56 Message: Logged In: YES user_id=945096 Okay, I'll see what I can do. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 23:53 Message: Logged In: YES user_id=33168 Albert, could you try to work up a patch implementing this? It would be much more likely to get fixed that way. It should also work with older Windows (9x/ME). Cheers, n ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 From noreply at sourceforge.net Sun Aug 13 04:16:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 19:16:06 -0700 Subject: [ python-Bugs-1539295 ] Long command lines don't work on Windows Message-ID: Bugs item #1539295, was opened at 2006-08-12 21:28 Message generated for change (Comment added) made by albertstrasheim You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this 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: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. ---------------------------------------------------------------------- >Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 04:16 Message: Logged In: YES user_id=945096 On further testing it seems this patch is a bit overzealous. The @ magic doesn't work for Windows commands in general. :-( ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 03:51 Message: Logged In: YES user_id=945096 New patch. Included a test case that fails without the changes and passes with the changes. Modified the code to incorporate some of nnorwitz's suggestions, except for the mkstemp change. The test case has a minor bug: the output of the build is still created relative to the the current working directory. I don't know distutils very well, so I'm not quite sure which option to mangle to fix this. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:44 Message: Logged In: YES user_id=945096 Okay, I'm going to try to implement some of your suggestions. A comment at the top of spawn.py says: # This module should be kept compatible with Python 2.1. but mkstemp was only added in Python 2.3. Is this comment still valid? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-13 02:17 Message: Logged In: YES user_id=33168 Ah, our msgs crossed. That explains the 2k. It would be nice to add a comment about that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-13 02:16 Message: Logged In: YES user_id=33168 Thanks for the patch! It looks pretty good, but there are a few changes (and additions) I would like to see. I don't understand why you use 2k in the patch, but mention the limit is 32k. You should use mkstemp() instead of mktemp(). That will open the file for you, so you can just do os.write(fd, data). You will need to close the file. I would prefer to see a single os.spawnv() call. You would need tmp defined (but possibly None) and in the finally, you would have to check if tmp: os.remove(). It would also be nice to see test and doc updates. The tests are in Lib/distutils/tests. Thanks again for the patch. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:09 Message: Logged In: YES user_id=945096 Looks like the max length on Windows 95 might be as low as 256 characters, but I'm not sure about this. It seems Windows 98 and Windows Me have a limit of 2048 characters. SCons assumes 2048 characters on any Windows system, so I did the same. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:03 Message: Logged In: YES user_id=945096 Attached a first try at a patch. Some things that could still be changed: - We might want to print a different log info message when using a temp file instead of calling the command directly - Restructure the code so that the spawnv call only appears in one place The setup.py I attached should allow anyone to duplicate this problem. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 23:56 Message: Logged In: YES user_id=945096 Okay, I'll see what I can do. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 23:53 Message: Logged In: YES user_id=33168 Albert, could you try to work up a patch implementing this? It would be much more likely to get fixed that way. It should also work with older Windows (9x/ME). Cheers, n ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 From noreply at sourceforge.net Sun Aug 13 04:20:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 19:20:49 -0700 Subject: [ python-Bugs-1437785 ] Problems w/ expat 1.95.7 vs. Python 2.4 Message-ID: <200608130220.k7D2Knhx020573@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1437785, was opened at 2006-02-23 15:59 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437785&group_id=5470 Please note that this 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: Closed Resolution: Fixed Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Problems w/ expat 1.95.7 vs. Python 2.4 Initial Comment: This may apply to the trunk as well... Today I finished installing 2.4.2 and all our local libraries at work. Trying out the main application I use I discovered Python segfaulting when trying to import pyexpat. It turned out that during the import an earlier module (gtk.glade) also wanted libexpat. Apparently pyexpat was expecting to get Expat 1.95.8 (what's delivered with Python) but got 1.95.7 instead (what we had installed and what was already linked with all our other Expat-using code). The solution was rather simple. I just commented out those constants in the pyexpat initialization that were marked as 1.95.8. Fortunately there was a comment identifying the version dependency. Is there some way that Python's build process can detect the Expat version and conditionally include/exclude bits that are for later versions? ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2006-08-12 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-29 03:41 Message: Logged In: YES user_id=849994 Should be fixed by patch #1295808. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-03-03 12:15 Message: Logged In: YES user_id=44345 Martin, I'm sorry. If I understood it better I'd explain it better. Tell me if this helps. We have expat 1.95.7 installed. We have C++ libraries that link with that version and are wrapped for use with Python using SWIG. Python 2.4 comes with 1.95.8. Apparently setup.py finds that and compiles pyexpat against it. In the pyexpat init function I see this block of constant initialization: /* Added in Expat 1.95.8. */ MYCONST(XML_ERROR_UNDECLARING_PREFIX); MYCONST(XML_ERROR_INCOMPLETE_PE); MYCONST(XML_ERROR_XML_DECL); MYCONST(XML_ERROR_TEXT_DECL); MYCONST(XML_ERROR_PUBLICID); MYCONST(XML_ERROR_SUSPENDED); MYCONST(XML_ERROR_NOT_SUSPENDED); MYCONST(XML_ERROR_ABORTED); MYCONST(XML_ERROR_FINISHED); MYCONST(XML_ERROR_SUSPEND_PE); If they are left in there, Python reliably segfaults at the first of those lines. When I exclude those lines, everything works fine. If I run ldd over pyexpat.so I don't see that libexpat is dynamically linked in: % ldd pyexpat.so libgcc_s.so.1 => /opt/lang/gcc-3.3.2/lib/libgcc_s.so.1 libc.so.1 => /lib/libc.so.1 libm.so.2 => /lib/libm.so.2 I thus have a statically linked version of libexpat 1.95.8 which appears to be exporting symbols: % nm -p pyexpat.so | egrep XML 0000042312 T XML_DefaultCurrent 0000042380 T XML_ErrorString 0000042428 T XML_ExpatVersion 0000042452 T XML_ExpatVersionInfo 0000039164 T XML_ExternalEntityParserCreate 0000042232 T XML_FreeContentModel 0000040580 T XML_GetBase 0000041584 T XML_GetBuffer ... Elsewhere I have a C++ library that is dynamically linked to 1.95.7, so I essentially have libexpat linked into the system twice. Does that seem like a reasonable description of our setup? If so, I can understand that trying to use (for example) XML_ERROR_UNDECLARING_PREFIX (which is new to 1.95.8) with symbols from libexpat 1.95.7 might create problems. I don't see how it could cause problems during constant initialization, but it does, quite reliably. You're much more savvy about these things than I am. Maybe you can see how this would happen. How do we tell Python's build process not to use the bundled 1.95.8? My local C++ gurus tell me they are not willing to rebuild everything with 1.95.8 just to make pyexpat happy. If we tell it that, then those constant initialization lines need to be conditionally exposed to the compiler so that it works to compile with libexpat 1.95.7. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-03-03 09:44 Message: Logged In: YES user_id=21627 I don't understand the problem. The build process should have picked-up the Python-provided expat, and should have ignored the system-installed one in all places (compiling, linking, running). What was the specific sequence of commands that you entered, what what the output you got, and what output would you have expected instead? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437785&group_id=5470 From noreply at sourceforge.net Sun Aug 13 04:20:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 19:20:48 -0700 Subject: [ python-Bugs-1246405 ] Segmentation fault when importing expat from xml.parser Message-ID: <200608130220.k7D2KmNM020561@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1246405, was opened at 2005-07-27 16:07 Message generated for change (Comment added) made by sf-robot 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: Closed Resolution: Fixed Priority: 5 Submitted By: Jean-Pierre (jean-pierre24) Assigned to: Nobody/Anonymous (nobody) Summary: Segmentation fault when importing expat from xml.parser Initial Comment: Hello, I have a strange segmentation fault when importing expat from xml.parsers in the following program (I removed all that is un-necessary to reproduce the bug, which is why the code may look odd). I've also posted this bug on wxPython bug lists because I'm not sure if it's related to Python or wxPython, but anyway the backtrace told me that the segmentation fault occurs when importing expat. import wx import wx.html class MainFrame(wx.Frame): def __init__(self, prnt): wx.Frame.__init__(self, parent=prnt) wx.html.HtmlWindow(wx.Window(self, -1), -1) print "debug 1" from xml.parsers import expat print "debug 2" class BoaApp(wx.App): def OnInit(self): wx.InitAllImageHandlers() MainFrame(None) return True app = BoaApp() The segmentation fault occurs between 'debug 1' and 'debug 2'. If I try to remove anything else, it doesn't happen. I have confirmed the bug on SunOS 5.8, on linux Red Hat Enterprise Server 3 and linux Advanced Server 3. I'm working with Python 2.4.1 and wxPython 2.6.1.0 Here is in attached file, the backtrace from gdb. Feel free to ask me any additional information... ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2006-08-12 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-29 03:36 Message: Logged In: YES user_id=849994 Patch 1295808 should have fixed this. Can you try it with Python 2.5b2? ---------------------------------------------------------------------- Comment By: Bernhard Herzog (bernhard) Date: 2005-12-01 05:51 Message: Logged In: YES user_id=2369 Could this be the same problem as bug 1075984 ? URL: https://sourceforge.net/tracker/index.php?func=detail&aid=1075984&group_id=5470&atid=105470 ---------------------------------------------------------------------- Comment By: Jean-Pierre (jean-pierre24) Date: 2005-10-06 13:23 Message: Logged In: YES user_id=1247525 Yes I can try with different version of wx, but it will take time. Anyway for today here is in attachment the valgrind output on linux x86. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-04 20:34 Message: Logged In: YES user_id=33168 I don't have the problem with Python 2.3.4 and wx 2.5.5.1. Are you able to try different versions of wxPython? I notice that wx 2.6.2 is available. Are you able to run under valgrind or purify? If you run under valgrind, be sure to specify --suppressions=Misc/valgrind-python.supp The file is in the Python distribution. You can download it through SourceForge ViewCVS. ---------------------------------------------------------------------- Comment By: Jean-Pierre (jean-pierre24) Date: 2005-10-04 15:05 Message: Logged In: YES user_id=1247525 Link is : http://sourceforge.net/tracker/index.php?func=detail&aid=1246397&group_id=9863&atid=109863 Unfortunately, absolutely nothing has happened since I reported the bug. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 22:10 Message: Logged In: YES user_id=33168 Can you provide a link to the wx bug report? Has anything happend with it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1246405&group_id=5470 From noreply at sourceforge.net Sun Aug 13 04:20:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 19:20:49 -0700 Subject: [ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI Message-ID: <200608130220.k7D2Kng8020567@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1075984, was opened at 2004-11-30 05:13 Message generated for change (Comment added) made by sf-robot 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: Closed Resolution: Fixed 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: SourceForge Robot (sf-robot) Date: 2006-08-12 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-29 03:39 Message: Logged In: YES user_id=849994 This should be addressed by patch #1295808. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-10-02 01:24 Message: Logged In: YES user_id=21627 I think the problem will occur whenever somebody loads libexpat.so with dlopen and RTLD_GLOBAL. IMO, this should be avoided. I can't see in which of these different reports this really is the case, but in those cases, this much looks like a third-party bug. If you import pyexpat first, it looks fine, since it will resolve the symbols against its own copy, without exporting them. Then, the later usage of libexpat cannot mistakenly go into pyexpat because Python loaded this with RTLD_LOCAL. However, it still may crash later when symbols are resolved lazily, as more expat symbols might be needed when using pyexpat, so different symbols might go to different libraries. Linking pyexpat with -Bsymbolic (where available) should also solve the problem. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-09-29 23:01 Message: Logged In: YES user_id=33168 The problem seems to be related (same?) as bug #1295808. Does the patch there fix these problems? ---------------------------------------------------------------------- Comment By: Steve Juranich (sjuranic) Date: 2005-07-19 09: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 10: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 15: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 02: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 22: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-01-31 23: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 05: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 05: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 01: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 09: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 08: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 08: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 Sun Aug 13 04:20:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Aug 2006 19:20:56 -0700 Subject: [ python-Bugs-1465014 ] CSV regression in 2.5a1: multi-line cells Message-ID: <200608130220.k7D2KuQ2020668@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1465014, was opened at 2006-04-05 08:14 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.5 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: David Goodger (goodger) Assigned to: Skip Montanaro (montanaro) Summary: CSV regression in 2.5a1: multi-line cells Initial Comment: Running the attached csv_test.py under Python 2.4.2 (Windows XP SP1) produces: >c:\apps\python24\python.exe ./csv_test.py ['one', '2', 'three (line 1)\n(line 2)'] Note that the third item in the row contains a newline between "(line 1)" and "(line 2)". With Python 2.5a1, I get: >c:\apps\python25\python.exe ./csv_test.py ['one', '2', 'three (line 1)(line 2)'] Notice the missing newline, which is significant. The CSV module under 2.5a1 seems to lose data. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2006-08-12 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-07-30 21:14 Message: Logged In: YES user_id=698599 Yep, your changes are reasonable. I considered adding an example, but couldn't think of anything that illustrated the point without confusing the reader further. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-07-30 20:13 Message: Logged In: YES user_id=44345 I'll see your 50993 and raise you a 50998. Just minor tweaks. Hopefully we can close this puppy, though a small example to make the idea concrete might be worthwhile. ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-07-30 19:41 Message: Logged In: YES user_id=698599 I've changed the comment again in changeset 50993 - hopefully this attempt describes the difference more fully. Let me know what you think. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-07-29 13:07 Message: Logged In: YES user_id=44345 I checked in a change to libcsv.tex (revision 50953). It adds a versionchanged bit to the reader doc that explains why the behavior changed in 2.5. Andrew & Andrew, please check my work. Sorry for the delay taking care of this. Skip ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-07-29 10:24 Message: Logged In: YES user_id=11375 I looked at this bug report, but I have no idea of exactly what behaviour has changed or what needs to be described. ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-22 20:34 Message: Logged In: YES user_id=698599 Yep, your point about adding a comment to the documentation is fair. Skip, do you want to take my words and massage them into a form suitable for the docs? ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-06-22 20:13 Message: Logged In: YES user_id=7733 I didn't realize that the previous behavior was buggy; I thought that the current behavior was a side-effect. The 2.5 behavior did cause a small problem in Docutils, but it's already been fixed. I just wanted to ensure that no regression was creeping in to 2.5. Thanks for the explanation! Perhaps it could be added to the docs in some form? Marking the bug report closed. ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-22 17:27 Message: Logged In: YES user_id=698599 The previous behaviour caused considerable problems, particularly on platforms that did not use the unix line- ending conventions, or with files that originated on those platforms - users were finding mysterious newlines where they didn't expect them. Quoted fields exist to allow characters that would otherwise be considered part of the syntax to appear within the field. So yes, quoted fields are a special case, and necessarily so. The current behaviour puts the control back in the hands of the user of the module: if literal newlines are important within a field, they need to read their file in a way that preserves the newlines. The old behaviour would introduce spurious characters into quoted fields, with no way for the user to control that behaviour. I'm sorry that the change causes you problems. With a format that's as loosely defined as CSV, it's an unfortunate fact of life that there are going to be conflicting requirements. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-06-22 11:17 Message: Logged In: YES user_id=7733 I see what you're saying, but I disagree. In Python 2.4, csv.reader did not require newlines, but in Python 2.5 it does. That's a significant behavioral change. In the stdlib csv "Module Contents" docs for csv.reader, it says: "csvfile can be any object which supports the iterator protocol and returns a string each time its next method is called." It doesn't mention newline-terminated strings. In any case, the behavior is inconsistent: newlines are not required to terminate row-ending strings, but only strings which end inside cells split across rows. Why the discrepancy? ---------------------------------------------------------------------- Comment By: Andrew McNamara (andrewmcnamara) Date: 2006-06-20 16:17 Message: Logged In: YES user_id=698599 I think your problem is with str.splitlines(), rather than the csv.reader: splitlines ate the newline. If you pass it True as an argument, it will retain the end-of-line character in the resulting strings. ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-05-02 14:04 Message: Logged In: YES user_id=7733 Assigned to Andrew McNamara, since his change appears to have caused this regression (revision 38290 on Modules/_csv.c). ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-05-02 13:58 Message: Logged In: YES user_id=7733 Further investigation has revealed that the regression only affects iterator I/O, not file I/O. The attached csv_test.py demonstrates. Run with Python 2.5 to get: results from file I/O: [['one', '2', 'three (line 1)\n(line 2)']] results from iterator I/O: [['one', '2', 'three (line 1)(line 2)']] ---------------------------------------------------------------------- Comment By: David Goodger (goodger) Date: 2006-04-05 08:44 Message: Logged In: YES user_id=7733 This bug seems to be a side effect of revision 38290 on Modules/_csv.c, which was prompted by bug 967934 (http://www.python.org/sf/967934). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1465014&group_id=5470 From noreply at sourceforge.net Mon Aug 14 04:20:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Aug 2006 19:20:28 -0700 Subject: [ python-Bugs-766842 ] Installing documentation doesn't make it show up Message-ID: <200608140220.k7E2KSit007287@sc8-sf-db2-new-b.sourceforge.net> Bugs item #766842, was opened at 2003-07-06 14:42 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766842&group_id=5470 Please note that this 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: Out of Date Priority: 3 Submitted By: Jack Jansen (jackjansen) Assigned to: Jack Jansen (jackjansen) Summary: Installing documentation doesn't make it show up Initial Comment: If you're installing the full Python documentation through Package Manager, but you've already run the IDE previously (the common case) the new documentation doesn't show up in the Apple Help Viewer. It does show up when you remove your help preferences. Probably a bug in the registration code in PythonIDE. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2006-08-13 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-30 04:04 Message: Logged In: YES user_id=849994 Should be obsolete as PythonIDE is deprecated... ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2003-07-21 14:07 Message: Logged In: YES user_id=45365 The IDE registration code turns out to be fine, so the problem is probably that if you do AHRegisterHelpBook() for an app for which you've done so before the call is simply ignored, in stead of the app being re-examined. This makes the problem difficult to fix right now. A possible fix would be to put the "MacPython Help" and "Python Documentation" into two different apps (the former in the IDE and the latter in Python.app?), but that's too much work for now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=766842&group_id=5470 From noreply at sourceforge.net Mon Aug 14 04:20:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Aug 2006 19:20:29 -0700 Subject: [ python-Bugs-780714 ] infinite __str__ recursion in thread causes seg fault Message-ID: <200608140220.k7E2KTF8007294@sc8-sf-db2-new-b.sourceforge.net> Bugs item #780714, was opened at 2003-07-31 01:37 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&group_id=5470 Please note that this 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: Stefan Gregory (stefan_gregory) Assigned to: Nobody/Anonymous (nobody) Summary: infinite __str__ recursion in thread causes seg fault Initial Comment: The following code reliably produces a segmentation fault under Solaris8 in Python2.3, Python2.2, Python2.1.3 and Python1.5. It produces a Bus Error when run on Python2.2 under OSX. Clearly it should produce a Python RuntimeError. import thread, time class Frog: def __str__(self): return str(self) f = Frog() thread.start_new_thread(str,(f,)) time.sleep(1000) This problem manifests in scenarios such as when you have 2 publishing objects (such as HTMLgen objects) A and B and you put A inside B and B inside A and each objects __str__ method calls its childrens __str__ methods and voila! (I hope this might be the reason my Zope server has been intermitently crashing for the past year or so though I have not found any recursive structures yet.) With Python2.3 gdb reports: vgetargskeywords (args=0x1bdaf0, keywords=0x0, format=0xd2579 "0:str", kwlist=0xf7b4c, p_va=0xfed0C02c) at Python/getargs.c:1167 Though with Python2.1 it dies at line 330 in getargs.c. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2006-08-13 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-30 04:16 Message: Logged In: YES user_id=849994 Under 2.5, I get a runtime error now, so this might be fixed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-05 12:22 Message: Logged In: YES user_id=357491 Forgot to mention that Modules/threadmodule.c has thread_PyThread_start_new_thread which uses Python/ thread_*.h's PyThread_start_new_thread for executing threads; the '*' is replaced with the threading library used on your platform. OS X should use thread_pthread.h (I think). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-05 12:19 Message: Logged In: YES user_id=357491 If you run ``str(Frog())`` instead of a bunch of threads you do get a RuntimeError. Looks like this bus error has something to do with thread.start_new_thread and not 'str'. It might be that since it runs using pthreads it does not have the built-in recursion limit check that the Python interpreter has. Anyone with more experience with the 'thread' module have any ideas? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&group_id=5470 From noreply at sourceforge.net Mon Aug 14 09:47:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 00:47:17 -0700 Subject: [ python-Bugs-1539847 ] Identifiers begining with __ renamed Message-ID: Bugs item #1539847, was opened at 2006-08-14 15:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539847&group_id=5470 Please note that this 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: W Barnes (w_barnes) Assigned to: Nobody/Anonymous (nobody) Summary: Identifiers begining with __ renamed Initial Comment: Identifiers used in a class function that start with __ are renamed to _classname__identifer even if the identifier is owned by some other object. Code snippet: size = len(Data.__entry_dates) Here I'm trying to access the identifier __entry_dates in the module Data from the function DataTestCase.testEntryDates() but I get the following: Traceback (most recent call last): File "DataTest.py", line 247, in testEntryDates size = len(Data.__entry_dates) AttributeError: 'module' object has no attribute '_DataTestCase__entry_dates' I'm using Python 2.4.3 on Windows XP sp2 Thanks, Walter ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539847&group_id=5470 From noreply at sourceforge.net Mon Aug 14 10:07:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 01:07:55 -0700 Subject: [ python-Bugs-1539847 ] Identifiers begining with __ renamed Message-ID: Bugs item #1539847, was opened at 2006-08-14 07:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539847&group_id=5470 Please note that this 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: W Barnes (w_barnes) Assigned to: Nobody/Anonymous (nobody) Summary: Identifiers begining with __ renamed Initial Comment: Identifiers used in a class function that start with __ are renamed to _classname__identifer even if the identifier is owned by some other object. Code snippet: size = len(Data.__entry_dates) Here I'm trying to access the identifier __entry_dates in the module Data from the function DataTestCase.testEntryDates() but I get the following: Traceback (most recent call last): File "DataTest.py", line 247, in testEntryDates size = len(Data.__entry_dates) AttributeError: 'module' object has no attribute '_DataTestCase__entry_dates' I'm using Python 2.4.3 on Windows XP sp2 Thanks, Walter ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-14 08:07 Message: Logged In: YES user_id=849994 This is exactly how __ name mangling is supposed to work. These are meant to be private, and thus shouldn't be accessed from another class. If the attribute was in another class, you could do the mangling (with the correct class name!) yourself, as it's on a module in this case, use __dict__: size = len(Data.__dict__['__entry_dates']) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539847&group_id=5470 From noreply at sourceforge.net Mon Aug 14 13:03:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 04:03:41 -0700 Subject: [ python-Bugs-1539925 ] warnings in interactive sessions Message-ID: Bugs item #1539925, was opened at 2006-08-14 13:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539925&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Nobody/Anonymous (nobody) Summary: warnings in interactive sessions Initial Comment: Carried over from Patch #1538956 description: During testing I found that the warning registry defaults to only issueing warnings once per module and line number. I suppose this is enough for debugging code, but it feels weird when trying things in the interactive session, as you only get the warnings once in that context (and for the whole session), regardless of the fact that you're entering new lines of code all the time. The reason is that the warning framework registers warnings based on line number which usually is 1 in interactive sessions. In general, it might be a better idea to have a single global warning registry and then include the module name or id in the registry key. Currently, the warning framework creates a new registry per (module) context. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539925&group_id=5470 From noreply at sourceforge.net Mon Aug 14 14:11:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 05:11:29 -0700 Subject: [ python-Bugs-1539954 ] Closing a pipe can lead to uncompleted command Message-ID: Bugs item #1539954, was opened at 2006-08-14 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=1539954&group_id=5470 Please note that this 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: Stefan Sonnenberg (sunmountain) Assigned to: Nobody/Anonymous (nobody) Summary: Closing a pipe can lead to uncompleted command Initial Comment: I'm using python version 2.3.3 (#0, Apr 22 2004, 11:33:00) [SunCC 5.5] under Solaris 9. I'm doing basically this: p = os.popen("cmd","w") p.write(cmd_string) p.close() Sometimes the command opened with popen does not work completely. A explicit p.flush() is needed to get the desired behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539954&group_id=5470 From noreply at sourceforge.net Mon Aug 14 14:12:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 05:12:00 -0700 Subject: [ python-Bugs-1539954 ] Closing a pipe can lead to uncompleted command Message-ID: Bugs item #1539954, was opened at 2006-08-14 14:11 Message generated for change (Settings changed) made by sunmountain You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539954&group_id=5470 Please note that this 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: Stefan Sonnenberg (sunmountain) Assigned to: Nobody/Anonymous (nobody) Summary: Closing a pipe can lead to uncompleted command Initial Comment: I'm using python version 2.3.3 (#0, Apr 22 2004, 11:33:00) [SunCC 5.5] under Solaris 9. I'm doing basically this: p = os.popen("cmd","w") p.write(cmd_string) p.close() Sometimes the command opened with popen does not work completely. A explicit p.flush() is needed to get the desired behaviour. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539954&group_id=5470 From noreply at sourceforge.net Mon Aug 14 14:14:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 05:14:35 -0700 Subject: [ python-Bugs-1539955 ] Insane format string should cause ValueError Message-ID: Bugs item #1539955, was opened at 2006-08-14 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=1539955&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Insane format string should cause ValueError Initial Comment: The documentation explicitly disallows mixing positional string interpolation and named string interpolation, but the following fails to raise an error: >>> "%s%(red)s" % dict(red=1, blue=2) "{'blue': 2, 'red': 1}1" Turning it around results in the wrong *kind* of error: >>> "%(red)s%s" % dict(red=1, blue=2) Traceback (most recent call last): File "", line 1, in TypeError: not enough arguments for format string A format string that mixes named and unnamed conversion specifiers should trigger a ValueError. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539955&group_id=5470 From noreply at sourceforge.net Mon Aug 14 14:19:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 05:19:07 -0700 Subject: [ python-Bugs-1539955 ] Insane format string should cause ValueError Message-ID: Bugs item #1539955, was opened at 2006-08-14 12:14 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539955&group_id=5470 Please note that this 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.6 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Insane format string should cause ValueError Initial Comment: The documentation explicitly disallows mixing positional string interpolation and named string interpolation, but the following fails to raise an error: >>> "%s%(red)s" % dict(red=1, blue=2) "{'blue': 2, 'red': 1}1" Turning it around results in the wrong *kind* of error: >>> "%(red)s%s" % dict(red=1, blue=2) Traceback (most recent call last): File "", line 1, in TypeError: not enough arguments for format string A format string that mixes named and unnamed conversion specifiers should trigger a ValueError. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-14 12:19 Message: Logged In: YES user_id=849994 This is the same issue as #1467929. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539955&group_id=5470 From noreply at sourceforge.net Mon Aug 14 16:18:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 07:18:37 -0700 Subject: [ python-Bugs-1538445 ] indent changes when copying command Message-ID: Bugs item #1538445, was opened at 2006-08-11 00:44 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1538445&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: mjd__ (mjd__) >Assigned to: Kurt B. Kaiser (kbk) Summary: indent changes when copying command Initial Comment: When copying a previous command by moving the cursor to the command and pressing 'enter', the indentation of the command is changed. The attached file is a saved session from the IDLE shell. mjd__/at/users/dot/sourceforge/dot/net ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-14 10:18 Message: Logged In: YES user_id=149084 Fixed 10 Aug @ 51189 2.5/1.2rc1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1538445&group_id=5470 From noreply at sourceforge.net Mon Aug 14 16:21:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 07:21:57 -0700 Subject: [ python-Bugs-1533481 ] CTypes _as_parameter_ not working as documented Message-ID: Bugs item #1533481, was opened at 2006-08-03 00:11 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533481&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Shane Holloway (shane_holloway) Assigned to: Nobody/Anonymous (nobody) Summary: CTypes _as_parameter_ not working as documented Initial Comment: Reference: http://docs.python.org/dev/lib/ctypes-calling-functions- with-own-custom-data-types.html According to this document, I should be able to use my own objects with ctypes, provided I have an _as_parameter_ attribute set on my object. However, this does not work properly when the foreign function's argtypes have been set. This is because the _as_parameter_ access is not done until after the argument types are checked. Attached is a patch that adds _as_parameter_ checking to the types provided by _ctypes.c so that the feature works as documented for both typed and untyped foreign functions. (Patch is against: svn rev 50859) ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-08-14 16:21 Message: Logged In: YES user_id=11105 The patch in http://python.org/sf/1532975 was committed together with the general idea of this patch as SVN revision 51277. ---------------------------------------------------------------------- Comment By: Shane Holloway (shane_holloway) Date: 2006-08-03 00:13 Message: Logged In: YES user_id=283742 A related patch is http://python.org/sf/1532975 that simplifies the implementation of _as_parameter_ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533481&group_id=5470 From noreply at sourceforge.net Mon Aug 14 16:53:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 07:53:12 -0700 Subject: [ python-Bugs-1530012 ] Literal strings use BS as octal escape character Message-ID: Bugs item #1530012, was opened at 2006-07-28 08:08 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530012&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: brucepeterson (brucepeterson) Assigned to: Nobody/Anonymous (nobody) Summary: Literal strings use BS as octal escape character Initial Comment: Also in 2.4 Using a literal to hard code a path. My directory happened to start with a number and I couldn't open the file due to the bad directory name. Found that the tripple quote was operating as documented. I would have at least expected the tripple double quotes to not have an escape character. (Is this a pep?) (From my reading of the Introduction, the triple double quotes should act like a raw string except that you can have a single double quote included in the string.) ------------- code snippet: ------------- dir1 = """C:\1stDirecotry""" dir2 = '''C:\2ndDirecotry''' dir3 = '''C:\9thDirecotry''' print dir1, dir2, dir3 C:?stDirecotry C:?ndDirecotry C:\9thDirecotry dir1's format was not expected, dir2's format might be expected. >>> '''\1''' '\x01' >>> '''\9''' '\\9' ---------------------------------------------------------------------- >Comment By: Nick Coghlan (ncoghlan) Date: 2006-08-15 00:53 Message: Logged In: YES user_id=1038590 Looking at the tutorial section on strings, it's almost certainly worth moving the introduction of triple-quoted string above the introduction of raw strings. At the moment, I can see how the OP could get the idea that the description of raw strings applied to triple-quoted strings as well. The other thing to do would be to explicitly mention backslash escaping problems in Section 7.2 where it discusses opening files, and the two possible solutions (use forward slashes in path literals regardless of platform, or else used doubled backslashes). I actually thought this was in the docs already, but it doesn't appear to be in any of the even vaguely obvious places (the files section in the tutorial, or the descriptions of file(), open(), file type or the os.path module in the library reference). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-29 13:25 Message: Logged In: YES user_id=33168 Triple quotes are just like single or double quotes wrt escaping. You need to prefix the string with an r: r"C:\1stDirecotry" to get what you want. This is probably documented in many places. I'm not sure where you looked or where you expected it to be documented. Can you suggest improvements? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530012&group_id=5470 From noreply at sourceforge.net Mon Aug 14 18:50:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 09:50:02 -0700 Subject: [ python-Feature Requests-1540112 ] Allow choice of copy function in shutil.copytree Message-ID: Feature Requests item #1540112, was opened at 2006-08-14 09:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1540112&group_id=5470 Please note that this 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: Tony (arandrea) Assigned to: Nobody/Anonymous (nobody) Summary: Allow choice of copy function in shutil.copytree Initial Comment: It would be nice to be able to choose which of the copy functions is used in copytree. I am currently working on a project where I would like to copy a tree, but I do not want to preserve permissions so I'd like copytree to use copyfile instead of copy2. Here is a snippet of copytree from shutil.py that I modified by adding a func parameter and defaulting it to copy2. def copytree(src, dst, symlinks=False, func=copy2): . . . try: if symlinks and os.path.islink(srcname): linkto = os.readlink(srcname) os.symlink(linkto, dstname) elif os.path.isdir(srcname): copytree(srcname, dstname, symlinks) else: func(srcname, dstname) . . . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1540112&group_id=5470 From noreply at sourceforge.net Mon Aug 14 19:24:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 10:24:49 -0700 Subject: [ python-Feature Requests-1540112 ] Allow choice of copy function in shutil.copytree Message-ID: Feature Requests item #1540112, was opened at 2006-08-14 09:49 Message generated for change (Comment added) made by arandrea You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1540112&group_id=5470 Please note that this 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: Tony (arandrea) Assigned to: Nobody/Anonymous (nobody) Summary: Allow choice of copy function in shutil.copytree Initial Comment: It would be nice to be able to choose which of the copy functions is used in copytree. I am currently working on a project where I would like to copy a tree, but I do not want to preserve permissions so I'd like copytree to use copyfile instead of copy2. Here is a snippet of copytree from shutil.py that I modified by adding a func parameter and defaulting it to copy2. def copytree(src, dst, symlinks=False, func=copy2): . . . try: if symlinks and os.path.islink(srcname): linkto = os.readlink(srcname) os.symlink(linkto, dstname) elif os.path.isdir(srcname): copytree(srcname, dstname, symlinks) else: func(srcname, dstname) . . . ---------------------------------------------------------------------- >Comment By: Tony (arandrea) Date: 2006-08-14 10:24 Message: Logged In: YES user_id=1575524 I guess I should have tested it first. I forgot to add the func parameter to the copytree call within copytree. Something like this: .try: . if symlinks and os.path.islink(srcname): . linkto = os.readlink(srcname) . os.symlink(linkto, dstname) . elif os.path.isdir(srcname): . copytree(srcname, dstname, symlinks, func) . else: . func(srcname, dstname) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1540112&group_id=5470 From noreply at sourceforge.net Mon Aug 14 23:34:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 14:34:30 -0700 Subject: [ python-Bugs-1224621 ] tokenize module does not detect inconsistent dedents Message-ID: Bugs item #1224621, was opened at 2005-06-21 06:10 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224621&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Danny Yoo (dyoo) Assigned to: Raymond Hettinger (rhettinger) Summary: tokenize module does not detect inconsistent dedents Initial Comment: The attached code snippet 'testcase.py' should produce an IndentationError, but does not. The code in tokenize.py is too trusting, and needs to add a check against bad indentation as it yields DEDENT tokens. I'm including a diff to tokenize.py that should at least raise an exception on bad indentation like this. Just in case, I'm including testcase.py here too: ------ import tokenize from StringIO import StringIO sampleBadText = """ def foo(): bar baz """ print list(tokenize.generate_tokens( StringIO(sampleBadText).readline)) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-14 21:34 Message: Logged In: YES user_id=849994 tabnanny's been taken care of in r51284. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-10 01:40 Message: Logged In: YES user_id=149084 Tokenize Rev 39046 21Jun05 breaks tabnanny. tabnanny doesn't handle the IndentationError exception when tokenize detects a dedent. I patched up ScriptBinding.py in IDLE. The IndentationError probably should pass the same parms as TokenError and tabnanny should catch it. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-02 12:40 Message: Logged In: YES user_id=4771 Here is a proposed patch. It relaxes the dedent policy a bit. It assumes that the first line may already have some initial indentation, as is the case when tokenizing from the middle of a file (as inspect.getsource() does). It should also be back-ported to 2.4, given that the previous patch was. For 2.4, only the non-test part of the patch applies cleanly; I suggest to ignore the test part and just apply it, given that there are much more tests in 2.5 for inspect.getsource() anyway. The whole issue of inspect.getsource() being muddy anyway, I will go ahead and check this patch in unless someone spots a problem. For now the previously-applied patch makes parts of PyPy break with an uncaught IndentationError. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-09-02 12:10 Message: Logged In: YES user_id=4771 Reopening this bug report: this might fix the problem at hand, but it breaks inspect.getsource() on cases where it used to work. See attached example. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-21 07:54 Message: Logged In: YES user_id=80475 Fixed. See Lib/tokenize.py 1.38 and 1.36.4.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1224621&group_id=5470 From noreply at sourceforge.net Tue Aug 15 06:48:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 21:48:13 -0700 Subject: [ python-Bugs-1540386 ] SocketServer.ForkingMixIn.collect_children() waits on pid 0 Message-ID: Bugs item #1540386, was opened at 2006-08-14 21:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1540386&group_id=5470 Please note that this 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: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer.ForkingMixIn.collect_children() waits on pid 0 Initial Comment: SocketServer.ForkingMixIn.collect_children() does: pid, status = os.waitpid(0, options) By setting pid = 0, it will wait on any children, even if the children were not started by the SocketServer. This causes sporadic test failures: http://mail.python.org/pipermail/python-dev/2006-August/068216.html It later assumes that if any child finished, that this server owned the process, which is not a valid assumption. Any part of the code could have spawned the child. I will fix the test suite, so this problem shouldn't occur (well at least reduce the likelihood by reaping the children before each test). I'm not certain how this problem should really be fixed (or if it's even worth fixing). Two possible solutions are: * only wait on the children we own * ignore returned pids that we don't own ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1540386&group_id=5470 From noreply at sourceforge.net Tue Aug 15 06:49:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Aug 2006 21:49:39 -0700 Subject: [ python-Bugs-1540386 ] SocketServer.ForkingMixIn.collect_children() waits on pid 0 Message-ID: Bugs item #1540386, was opened at 2006-08-14 21:48 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1540386&group_id=5470 Please note that this 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: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer.ForkingMixIn.collect_children() waits on pid 0 Initial Comment: SocketServer.ForkingMixIn.collect_children() does: pid, status = os.waitpid(0, options) By setting pid = 0, it will wait on any children, even if the children were not started by the SocketServer. This causes sporadic test failures: http://mail.python.org/pipermail/python-dev/2006-August/068216.html It later assumes that if any child finished, that this server owned the process, which is not a valid assumption. Any part of the code could have spawned the child. I will fix the test suite, so this problem shouldn't occur (well at least reduce the likelihood by reaping the children before each test). I'm not certain how this problem should really be fixed (or if it's even worth fixing). Two possible solutions are: * only wait on the children we own * ignore returned pids that we don't own ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-14 21:49 Message: Logged In: YES user_id=33168 I forgot to mention that this problem seems to have sporadically hit many of the buildbots. Though it seemed to always occur on cygwin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1540386&group_id=5470 From noreply at sourceforge.net Tue Aug 15 12:31:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 03:31:58 -0700 Subject: [ python-Bugs-1540529 ] cgi.py error on parsing/handling content-disposition Message-ID: Bugs item #1540529, was opened at 2006-08-15 12:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1540529&group_id=5470 Please note that this 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: Dirk Holtwick (holtwick) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.py error on parsing/handling content-disposition Initial Comment: A header like this one containing a ";" and blanks in the content disposition fails: Content-Disposition: form-data; name="_media"; filename="Demo; 28.07.2006.jpg" The cause is, that the function parse_header() first splits the line by ";" and then begins to analize these parts. The part "filename" in our example is then split into two separate parts. I wrote a fix for the function parse_header(). It isn't still complete, because escaped '"' on the end of line are not respected, but in most cases it helps. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1540529&group_id=5470 From noreply at sourceforge.net Tue Aug 15 17:06:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 08:06:44 -0700 Subject: [ python-Bugs-1540386 ] SocketServer.ForkingMixIn.collect_children() waits on pid 0 Message-ID: Bugs item #1540386, was opened at 2006-08-15 00:48 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1540386&group_id=5470 Please note that this 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: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer.ForkingMixIn.collect_children() waits on pid 0 Initial Comment: SocketServer.ForkingMixIn.collect_children() does: pid, status = os.waitpid(0, options) By setting pid = 0, it will wait on any children, even if the children were not started by the SocketServer. This causes sporadic test failures: http://mail.python.org/pipermail/python-dev/2006-August/068216.html It later assumes that if any child finished, that this server owned the process, which is not a valid assumption. Any part of the code could have spawned the child. I will fix the test suite, so this problem shouldn't occur (well at least reduce the likelihood by reaping the children before each test). I'm not certain how this problem should really be fixed (or if it's even worth fixing). Two possible solutions are: * only wait on the children we own * ignore returned pids that we don't own ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-15 11:06 Message: Logged In: YES user_id=6380 It should keep track of the pids of all its children and only wait for those. Shouldn't be hard. Can be done in 2.5.1 since it's a bugfix. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-15 00:49 Message: Logged In: YES user_id=33168 I forgot to mention that this problem seems to have sporadically hit many of the buildbots. Though it seemed to always occur on cygwin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1540386&group_id=5470 From noreply at sourceforge.net Wed Aug 16 04:10:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 19:10:04 -0700 Subject: [ python-Bugs-1539847 ] Identifiers begining with __ renamed Message-ID: Bugs item #1539847, was opened at 2006-08-14 15:47 Message generated for change (Comment added) made by w_barnes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539847&group_id=5470 Please note that this 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: W Barnes (w_barnes) Assigned to: Nobody/Anonymous (nobody) Summary: Identifiers begining with __ renamed Initial Comment: Identifiers used in a class function that start with __ are renamed to _classname__identifer even if the identifier is owned by some other object. Code snippet: size = len(Data.__entry_dates) Here I'm trying to access the identifier __entry_dates in the module Data from the function DataTestCase.testEntryDates() but I get the following: Traceback (most recent call last): File "DataTest.py", line 247, in testEntryDates size = len(Data.__entry_dates) AttributeError: 'module' object has no attribute '_DataTestCase__entry_dates' I'm using Python 2.4.3 on Windows XP sp2 Thanks, Walter ---------------------------------------------------------------------- >Comment By: W Barnes (w_barnes) Date: 2006-08-16 10:10 Message: Logged In: YES user_id=1541460 Thanks! I was unaware that name mangling applied to global attributes as well as class attributes. The error message is a bit misleading though. If I define __widget in foo then access it from bar as foo.__widget why does it rename it as _bar__widget if it was not defined there? If it needs to do this internally why not use the unmangled name for the error message? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-14 16:07 Message: Logged In: YES user_id=849994 This is exactly how __ name mangling is supposed to work. These are meant to be private, and thus shouldn't be accessed from another class. If the attribute was in another class, you could do the mangling (with the correct class name!) yourself, as it's on a module in this case, use __dict__: size = len(Data.__dict__['__entry_dates']) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539847&group_id=5470 From noreply at sourceforge.net Wed Aug 16 04:20:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 19:20:34 -0700 Subject: [ python-Bugs-1527397 ] PythonLauncher uses incorrect working directory Message-ID: <200608160220.k7G2KYcT006282@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1527397, was opened at 2006-07-23 10:29 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527397&group_id=5470 Please note that this 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.5 >Status: Closed Resolution: Fixed Priority: 7 Submitted By: Bob Ippolito (etrepum) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: PythonLauncher uses incorrect working directory Initial Comment: PythonLauncher, the application used to launch .py files by double-click, does not launch with the correct working directory. This means that any script that depends on data files will not work via PythonLauncher. Users expect the working directory to be that of the launched script, like on other platforms, but PythonLauncher launches with a working directory of $HOME. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2006-08-15 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-01 14:02 Message: Logged In: YES user_id=580910 Fixed in revision 51028. Please confirm. The same revision also fixes a problem where PythonLauncher failed to launch scripts if the name contains quotes (e.g. "Ronald's Script.py"). ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-23 11:50 Message: Logged In: YES user_id=580910 I agree that the current behaviour is not what users expect and should be considered a bug. I'd like to get the attached patch into 2.5, it changes the CWD to the directory containing the script and should be perfectly save. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1527397&group_id=5470 From noreply at sourceforge.net Wed Aug 16 06:11:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 21:11:09 -0700 Subject: [ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails Message-ID: Bugs item #1531862, was opened at 2006-07-31 09:53 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 Please note that this 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: John A Meinel (jfmeinel) Assigned to: Peter ?strand (astrand) Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails Initial Comment: I'm currently using subprocess.Popen() to run a command, and I allow the caller to specify where the output should go. One valid output is to send it to sys.stdout (fileno == 1) The subprocess module seems to unconditionally close stdout if a file handle is passed (even if it stdout). Compare: python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'])" versus python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)" or even python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=1)" The first one prints 'hello' as expected. The latter two give an error: echo: write error: Bad file descriptor Attached is a possible patch to subprocess.py ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-15 21:11 Message: Logged In: YES user_id=33168 If stderr == stdout, this patch won't fix that, will it? Shouldn't you add 1, 2 to the blacklist for stderr? (The patch adds 2, I think 1 may also be required.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 From noreply at sourceforge.net Wed Aug 16 06:16:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 21:16:08 -0700 Subject: [ python-Bugs-1531862 ] subprocess.Popen(cmd, stdout=sys.stdout) fails Message-ID: Bugs item #1531862, was opened at 2006-08-01 02:53 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 Please note that this 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: John A Meinel (jfmeinel) Assigned to: Peter ?strand (astrand) Summary: subprocess.Popen(cmd, stdout=sys.stdout) fails Initial Comment: I'm currently using subprocess.Popen() to run a command, and I allow the caller to specify where the output should go. One valid output is to send it to sys.stdout (fileno == 1) The subprocess module seems to unconditionally close stdout if a file handle is passed (even if it stdout). Compare: python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'])" versus python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=sys.stdout)" or even python -c "import subprocess,sys; \ subprocess.Popen(['echo', 'hello'], stdout=1)" The first one prints 'hello' as expected. The latter two give an error: echo: write error: Bad file descriptor Attached is a possible patch to subprocess.py ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-08-16 14:16 Message: Logged In: YES user_id=29957 Making it check for particular FD numbers is a bad idea. Instead, it should check that any FD that's being closed isn't in the set (sys.stdin.fileno(), sys.stdout.fileno(), sys.stderr.fileno()) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-16 14:11 Message: Logged In: YES user_id=33168 If stderr == stdout, this patch won't fix that, will it? Shouldn't you add 1, 2 to the blacklist for stderr? (The patch adds 2, I think 1 may also be required.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531862&group_id=5470 From noreply at sourceforge.net Wed Aug 16 06:29:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 21:29:44 -0700 Subject: [ python-Bugs-1539847 ] Identifiers begining with __ renamed Message-ID: Bugs item #1539847, was opened at 2006-08-14 15:47 Message generated for change (Comment added) made by w_barnes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539847&group_id=5470 Please note that this 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: W Barnes (w_barnes) Assigned to: Nobody/Anonymous (nobody) Summary: Identifiers begining with __ renamed Initial Comment: Identifiers used in a class function that start with __ are renamed to _classname__identifer even if the identifier is owned by some other object. Code snippet: size = len(Data.__entry_dates) Here I'm trying to access the identifier __entry_dates in the module Data from the function DataTestCase.testEntryDates() but I get the following: Traceback (most recent call last): File "DataTest.py", line 247, in testEntryDates size = len(Data.__entry_dates) AttributeError: 'module' object has no attribute '_DataTestCase__entry_dates' I'm using Python 2.4.3 on Windows XP sp2 Thanks, Walter ---------------------------------------------------------------------- >Comment By: W Barnes (w_barnes) Date: 2006-08-16 12:29 Message: Logged In: YES user_id=1541460 I just noticed some more weirdness in regards to name mangling... Apparently there is no way for a class to access global attributes that are declared private. That is if a module 'foo' has a global attribute '__widget' a class 'bar' also defined in foo will get the following error if it attempts to access __widget: NameError: global name '_bar__widget' is not defined Using either _foo__widget directly or __dict__ doesn't work. For now, I can get around this by using a non-private global helper function as a middle man. I'm a Python newbie but, for what it's worth, here are some suggestions: First, if an attribute is accessed as a child of some object other than 'self' or the name of the enclosing class no name mangling should be done. It seems that name mangling isn't necessary here as an attribute error will all ways be raised whether or not the object has that attribute. Second, when searching for a global attribute that begins with __ it should be renamed to reflect the name of the module not the enclosing class. In the example above, if _bar__widget cannot be found in bar then it should look for _foo__widget in the global namespace. Finally, as I mentioned before, for clarity if no match is found the error message should include the unmangled name. ---------------------------------------------------------------------- Comment By: W Barnes (w_barnes) Date: 2006-08-16 10:10 Message: Logged In: YES user_id=1541460 Thanks! I was unaware that name mangling applied to global attributes as well as class attributes. The error message is a bit misleading though. If I define __widget in foo then access it from bar as foo.__widget why does it rename it as _bar__widget if it was not defined there? If it needs to do this internally why not use the unmangled name for the error message? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-14 16:07 Message: Logged In: YES user_id=849994 This is exactly how __ name mangling is supposed to work. These are meant to be private, and thus shouldn't be accessed from another class. If the attribute was in another class, you could do the mangling (with the correct class name!) yourself, as it's on a module in this case, use __dict__: size = len(Data.__dict__['__entry_dates']) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539847&group_id=5470 From noreply at sourceforge.net Wed Aug 16 07:03:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 22:03:47 -0700 Subject: [ python-Bugs-1479785 ] Quitter object masked Message-ID: Bugs item #1479785, was opened at 2006-05-01 11:01 Message generated for change (Settings changed) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479785&group_id=5470 Please note that this 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.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Kurt B. Kaiser (kbk) Summary: Quitter object masked Initial Comment: 2.5 introduces a Quitter object (defined in site.py) to make the quit/exit message more friendly. Lines 480-482 of PyShell.py override this, so that users of Idle never see the improved feature. Unfortunately, simply removing those lines isn't quite enough to solve the problem, as IDLE catches SystemExit exceptions. Getting around that, I didn't have time to track down yet. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-16 01:03 Message: Logged In: YES user_id=149084 Rev 51306: Patch #1540892 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479785&group_id=5470 From noreply at sourceforge.net Wed Aug 16 08:34:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Aug 2006 23:34:23 -0700 Subject: [ python-Bugs-1539847 ] Identifiers begining with __ renamed Message-ID: Bugs item #1539847, was opened at 2006-08-14 07:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539847&group_id=5470 Please note that this 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: W Barnes (w_barnes) Assigned to: Nobody/Anonymous (nobody) Summary: Identifiers begining with __ renamed Initial Comment: Identifiers used in a class function that start with __ are renamed to _classname__identifer even if the identifier is owned by some other object. Code snippet: size = len(Data.__entry_dates) Here I'm trying to access the identifier __entry_dates in the module Data from the function DataTestCase.testEntryDates() but I get the following: Traceback (most recent call last): File "DataTest.py", line 247, in testEntryDates size = len(Data.__entry_dates) AttributeError: 'module' object has no attribute '_DataTestCase__entry_dates' I'm using Python 2.4.3 on Windows XP sp2 Thanks, Walter ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-16 06:34 Message: Logged In: YES user_id=849994 > The error message is a bit misleading though. If I define > __widget in foo then access it from bar as foo.__widget > why does it rename it as _bar__widget if it was not > defined there? If it needs to do this internally why not > use the unmangled name for the error message? This is how name mangling works. All __x attribute access in a class is mangled with *this* class's name -- it happens in the compiling stage, where the compiler doesn't know anything but this name (this also rules out changing the error message). In case of other classes' attributes this is fine since the attribute is *supposed* to be private to this other class. With global __x variables, the advice is "don't do that". Still, I have no problem accessing them through the module's __dict__, unmangled of course. ---------------------------------------------------------------------- Comment By: W Barnes (w_barnes) Date: 2006-08-16 04:29 Message: Logged In: YES user_id=1541460 I just noticed some more weirdness in regards to name mangling... Apparently there is no way for a class to access global attributes that are declared private. That is if a module 'foo' has a global attribute '__widget' a class 'bar' also defined in foo will get the following error if it attempts to access __widget: NameError: global name '_bar__widget' is not defined Using either _foo__widget directly or __dict__ doesn't work. For now, I can get around this by using a non-private global helper function as a middle man. I'm a Python newbie but, for what it's worth, here are some suggestions: First, if an attribute is accessed as a child of some object other than 'self' or the name of the enclosing class no name mangling should be done. It seems that name mangling isn't necessary here as an attribute error will all ways be raised whether or not the object has that attribute. Second, when searching for a global attribute that begins with __ it should be renamed to reflect the name of the module not the enclosing class. In the example above, if _bar__widget cannot be found in bar then it should look for _foo__widget in the global namespace. Finally, as I mentioned before, for clarity if no match is found the error message should include the unmangled name. ---------------------------------------------------------------------- Comment By: W Barnes (w_barnes) Date: 2006-08-16 02:10 Message: Logged In: YES user_id=1541460 Thanks! I was unaware that name mangling applied to global attributes as well as class attributes. The error message is a bit misleading though. If I define __widget in foo then access it from bar as foo.__widget why does it rename it as _bar__widget if it was not defined there? If it needs to do this internally why not use the unmangled name for the error message? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-14 08:07 Message: Logged In: YES user_id=849994 This is exactly how __ name mangling is supposed to work. These are meant to be private, and thus shouldn't be accessed from another class. If the attribute was in another class, you could do the mangling (with the correct class name!) yourself, as it's on a module in this case, use __dict__: size = len(Data.__dict__['__entry_dates']) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539847&group_id=5470 From noreply at sourceforge.net Wed Aug 16 09:42:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 00:42:09 -0700 Subject: [ python-Bugs-780714 ] infinite __str__ recursion in thread causes seg fault Message-ID: Bugs item #780714, was opened at 2003-07-31 01:37 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&group_id=5470 Please note that this 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: Stefan Gregory (stefan_gregory) Assigned to: Nobody/Anonymous (nobody) Summary: infinite __str__ recursion in thread causes seg fault Initial Comment: The following code reliably produces a segmentation fault under Solaris8 in Python2.3, Python2.2, Python2.1.3 and Python1.5. It produces a Bus Error when run on Python2.2 under OSX. Clearly it should produce a Python RuntimeError. import thread, time class Frog: def __str__(self): return str(self) f = Frog() thread.start_new_thread(str,(f,)) time.sleep(1000) This problem manifests in scenarios such as when you have 2 publishing objects (such as HTMLgen objects) A and B and you put A inside B and B inside A and each objects __str__ method calls its childrens __str__ methods and voila! (I hope this might be the reason my Zope server has been intermitently crashing for the past year or so though I have not found any recursive structures yet.) With Python2.3 gdb reports: vgetargskeywords (args=0x1bdaf0, keywords=0x0, format=0xd2579 "0:str", kwlist=0xf7b4c, p_va=0xfed0C02c) at Python/getargs.c:1167 Though with Python2.1 it dies at line 330 in getargs.c. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-08-16 00:42 Message: Logged In: YES user_id=341410 >>> import sys >>> sys.setrecursionlimit(10000) >>> class foo: ... def __str__(self): ... return str(self) ... >>> import threading >>> threading.Thread(target=foo().__str__).start() Kills 2.3, 2.4, and 2.5 on Windows, and 2.3 and 2.4 on linux (I can't test 2.5 on linux). Running in the main thread on Windows doesn't seem to be a big deal: >>> import sys >>> sys.setrecursionlimit(10000) >>> class foo: ... def __str__(self): ... return str(self) ... >>> try: ... str(foo()) ... except Exception, why: ... print why ... Stack overflow >>> Note that the above crashes 2.3 and 2.4 on Linux. This is still a bug, at least in maintenance on 2.4. Suggested reopen. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-08-13 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-30 04:16 Message: Logged In: YES user_id=849994 Under 2.5, I get a runtime error now, so this might be fixed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-05 12:22 Message: Logged In: YES user_id=357491 Forgot to mention that Modules/threadmodule.c has thread_PyThread_start_new_thread which uses Python/ thread_*.h's PyThread_start_new_thread for executing threads; the '*' is replaced with the threading library used on your platform. OS X should use thread_pthread.h (I think). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-05 12:19 Message: Logged In: YES user_id=357491 If you run ``str(Frog())`` instead of a bunch of threads you do get a RuntimeError. Looks like this bus error has something to do with thread.start_new_thread and not 'str'. It might be that since it runs using pthreads it does not have the built-in recursion limit check that the Python interpreter has. Anyone with more experience with the 'thread' module have any ideas? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&group_id=5470 From noreply at sourceforge.net Wed Aug 16 15:08:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 06:08:07 -0700 Subject: [ python-Bugs-1535502 ] Python 2.5 windows builds should link hashlib with OpenSSL Message-ID: Bugs item #1535502, was opened at 2006-08-06 21:38 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535502&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gregory P. Smith (greg) Assigned to: Anthony Baxter (anthonybaxter) Summary: Python 2.5 windows builds should link hashlib with OpenSSL Initial Comment: The Windows builds of Python 2.5 need to be updated to build and link the hashlib modules with OpenSSL 0.9.8. The OpenSSL implementations of the hash algorithms are *much* faster (often 2-3x) than the fallback C implementations that python includes for use when OpenSSL isn't available. I just tested the python 2.5b3 installer on windows. its using the fallback versions rather than OpenSSL: here's a simple way to check from a running python: Without OpenSSL: >>> import hashlib >>> hashlib.sha1 With OpenSSL: >>> import hashlib >>> hashlib.sha1 (please use openssl 0.9.8; older versions don't include sha256 and sha512 implementations) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-16 15:08 Message: Logged In: YES user_id=21627 With Anthony's approval, this is now committed as r51310. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-09 16:34 Message: Logged In: YES user_id=21627 I changed the patch to support the Win64 build process, and added packaging support (msi.py). It looks fine to me now. Anthony, is this ok to apply? ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-08-08 09:48 Message: Logged In: YES user_id=413 attached is a patch that works for me on Win XP with MSVS 2003 (vc++ 7.1): build_hashlib_with_ssl-01.patch It does several things: build_ssl.py -- this is fixed to use do_masm.bat instead of a modified 32all.bat to build OpenSSL with x86 asm optimizations on Win32. It is also fixed to work when under a directory tree with spaces in the directory names. _ssl.mak -- since both _ssl and _hashlib depend on OpenSSL it made the most sense for both to be built by the same makefile. I added _hashlib's build here. _ssl.vcproj -- adds the dependancy on Modules/_hashopenssl.c Things still TODO - make sure _hashlib.pyd is added to the MSI installer. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-08-08 08:02 Message: Logged In: YES user_id=413 i've attached a patch to PCbuild/build_ssl.py that should build the assembly optimized OpenSSL on windows by default. Still todo: a _hashlib.vcproj file is needed. though wouldn't it be easier for me to just build _hashlib.pyd from within the _ssl.mak file? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1535502&group_id=5470 From noreply at sourceforge.net Wed Aug 16 15:12:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 06:12:11 -0700 Subject: [ python-Bugs-1539954 ] Closing a pipe can lead to uncompleted command Message-ID: Bugs item #1539954, was opened at 2006-08-14 14:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539954&group_id=5470 Please note that this 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: Stefan Sonnenberg (sunmountain) Assigned to: Nobody/Anonymous (nobody) Summary: Closing a pipe can lead to uncompleted command Initial Comment: I'm using python version 2.3.3 (#0, Apr 22 2004, 11:33:00) [SunCC 5.5] under Solaris 9. I'm doing basically this: p = os.popen("cmd","w") p.write(cmd_string) p.close() Sometimes the command opened with popen does not work completely. A explicit p.flush() is needed to get the desired behaviour. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-16 15:12 Message: Logged In: YES user_id=21627 I can't reproduce this, and I can't see anything in the Python source code that might be causing it. Can you provide a reproducable test case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539954&group_id=5470 From noreply at sourceforge.net Wed Aug 16 15:15:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 06:15:45 -0700 Subject: [ python-Bugs-1539295 ] Long command lines don't work on Windows Message-ID: Bugs item #1539295, was opened at 2006-08-12 21:28 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 Please note that this 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: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Albert Strasheim (albertstrasheim) Assigned to: Nobody/Anonymous (nobody) Summary: Long command lines don't work on Windows Initial Comment: Windows has a 32k command line limit, described here: http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx The SciPy project is running into problems when using distutils to compile LAPACK from source, because the large number of source files results in a command line of more than 70,000 characters. Windows has a way of dealing with this problem, namely putting the command line arguments in a file and passing that file to executable with prepended with an @, i.e. you want to run something like lib.exe @tempdir\tempargs.lnk SCons takes care of this through it's TEMPFILE mechanism which uses the TempFileMunge class which can be perused here: http://scons.tigris.org/source/browse/scons/trunk/src/engine/SCons/Platform/__init__.py?rev=1582&view=markup I think this problem can easily be addressed in distutils by modifying the _spawn_nt method in spawn.py to switch to this temp file method when the command line length exceeds some threshold. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-16 15:15 Message: Logged In: YES user_id=21627 As you just found out, this isn't a Windows feature. It's a feature of certain command line tools; primarily, it's a feature of the Visual Studio and PSDK command line tools. Each tool has to implement this machinery for itself. So I'm closing this as "won't fix"; alternatively, it could be closed as "third-party bug" (i.e. Windows limitation). ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 04:16 Message: Logged In: YES user_id=945096 On further testing it seems this patch is a bit overzealous. The @ magic doesn't work for Windows commands in general. :-( ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 03:51 Message: Logged In: YES user_id=945096 New patch. Included a test case that fails without the changes and passes with the changes. Modified the code to incorporate some of nnorwitz's suggestions, except for the mkstemp change. The test case has a minor bug: the output of the build is still created relative to the the current working directory. I don't know distutils very well, so I'm not quite sure which option to mangle to fix this. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:44 Message: Logged In: YES user_id=945096 Okay, I'm going to try to implement some of your suggestions. A comment at the top of spawn.py says: # This module should be kept compatible with Python 2.1. but mkstemp was only added in Python 2.3. Is this comment still valid? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-13 02:17 Message: Logged In: YES user_id=33168 Ah, our msgs crossed. That explains the 2k. It would be nice to add a comment about that. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-13 02:16 Message: Logged In: YES user_id=33168 Thanks for the patch! It looks pretty good, but there are a few changes (and additions) I would like to see. I don't understand why you use 2k in the patch, but mention the limit is 32k. You should use mkstemp() instead of mktemp(). That will open the file for you, so you can just do os.write(fd, data). You will need to close the file. I would prefer to see a single os.spawnv() call. You would need tmp defined (but possibly None) and in the finally, you would have to check if tmp: os.remove(). It would also be nice to see test and doc updates. The tests are in Lib/distutils/tests. Thanks again for the patch. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:09 Message: Logged In: YES user_id=945096 Looks like the max length on Windows 95 might be as low as 256 characters, but I'm not sure about this. It seems Windows 98 and Windows Me have a limit of 2048 characters. SCons assumes 2048 characters on any Windows system, so I did the same. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-13 02:03 Message: Logged In: YES user_id=945096 Attached a first try at a patch. Some things that could still be changed: - We might want to print a different log info message when using a temp file instead of calling the command directly - Restructure the code so that the spawnv call only appears in one place The setup.py I attached should allow anyone to duplicate this problem. ---------------------------------------------------------------------- Comment By: Albert Strasheim (albertstrasheim) Date: 2006-08-12 23:56 Message: Logged In: YES user_id=945096 Okay, I'll see what I can do. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-12 23:53 Message: Logged In: YES user_id=33168 Albert, could you try to work up a patch implementing this? It would be much more likely to get fixed that way. It should also work with older Windows (9x/ME). Cheers, n ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539295&group_id=5470 From noreply at sourceforge.net Wed Aug 16 15:18:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 06:18:33 -0700 Subject: [ python-Feature Requests-1538778 ] pyo's are not overwritten by different optimization levels Message-ID: Feature Requests item #1538778, was opened at 2006-08-11 17:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1538778&group_id=5470 Please note that this 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: Toshio Kuratomi (abadger1999) Assigned to: Nobody/Anonymous (nobody) Summary: pyo's are not overwritten by different optimization levels Initial Comment: If I invoke "python -OO" on a set of files, python creates a set of .pyo files. If I then realize this is an incredibly stupid thing to do because it removes the docstrings from the output and this program requires those docstrings python does not give me a method of overwriting the generated .pyos. I anticipated that running "python -O" would detect that the already generated .pyos were created in a different optimixation level and overwrite them with new .pyos. Barring that, I expected there to be a command line switch to tell python to overwrite the previously generated .pyo cache files. Finding neither, I realized that the only way to recover docstrings for people using python -O was to rm all the generated .pyo files. This seems like a bug or a missing feature. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-16 15:18 Message: Logged In: YES user_id=21627 This is a feature request; classifying it as such. See also PEP 304 (notice it has been withdrawn). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1538778&group_id=5470 From noreply at sourceforge.net Wed Aug 16 15:22:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 06:22:13 -0700 Subject: [ python-Bugs-1532920 ] os.path.isfile('CON:') does not behave as documented Message-ID: Bugs item #1532920, was opened at 2006-08-02 07:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532920&group_id=5470 Please note that this 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: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: os.path.isfile('CON:') does not behave as documented Initial Comment: In Windows, os.path.isfile() returns True for device filenames such as 'CON:', 'NUL:', 'AUX:', 'PRN:', and 'C:\\Program Files\\con.mp3'. The documentation for os.path.isfile() says that it returns True only for regular files, so it should return False for the above examples (or else the documentation should be amended). In Linux, os.path.isfile('/dev/null') returns False as expected. This problem occurs because the ?stat? function in Microsoft?s C library behaves differently than in *nix. Quoting from Microsoft's documentation for stat: ?st_mode: ... the _S_IFREG bit is set if path specifies an ordinary file or a device? http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt__stat.2c_._wstat.2c_._stati64.2c_._wstati64.asp A similar problem exists with stat.S_ISREG(os.stat('CON:').st_mode) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-16 15:22 Message: Logged In: YES user_id=21627 This is fixed in Python 2.5, which dropped usage of the mscvrt stat implementation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1532920&group_id=5470 From noreply at sourceforge.net Wed Aug 16 15:25:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 06:25:06 -0700 Subject: [ python-Bugs-1530142 ] Mac Universal Build of Python confuses distutils Message-ID: Bugs item #1530142, was opened at 2006-07-28 08:02 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530142&group_id=5470 Please note that this 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: Richard Jones (richard) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: Mac Universal Build of Python confuses distutils Initial Comment: I'm sorry I can't provide a fully-detailed report here, but I'm not in a position to be able to reproduce the problem. In short, I installed the Universal build of Python 2.4.3 for the Mac downloaded from: http://pythonmac.org/packages/py24-fat/index.html I don't know whether this is the same as the download from: http://www.python.org/download/releases/2.4.3/ Once installed, I attempted to build ctypes. The build failed due to an assembly error (unknown instruction). I'm not familiar with the PPC or x86 assembler code so couldn't do a thorough analysis. I needed Python2.4 to work, so I found an older PPC-only installer and used that. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-16 15:25 Message: Logged In: YES user_id=21627 This might be a ctypes limitation: it might be that ctypes doesn't support x86-OSX (atleast in this release). ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2006-07-28 08:47 Message: Logged In: YES user_id=6405 0.9.9.6 ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-28 08:28 Message: Logged In: YES user_id=580910 Which version of ctypes did you try to build? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530142&group_id=5470 From noreply at sourceforge.net Wed Aug 16 15:28:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 06:28:36 -0700 Subject: [ python-Bugs-1539954 ] Closing a pipe can lead to uncompleted command Message-ID: Bugs item #1539954, was opened at 2006-08-14 14:11 Message generated for change (Comment added) made by sunmountain You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539954&group_id=5470 Please note that this 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: Stefan Sonnenberg (sunmountain) Assigned to: Nobody/Anonymous (nobody) Summary: Closing a pipe can lead to uncompleted command Initial Comment: I'm using python version 2.3.3 (#0, Apr 22 2004, 11:33:00) [SunCC 5.5] under Solaris 9. I'm doing basically this: p = os.popen("cmd","w") p.write(cmd_string) p.close() Sometimes the command opened with popen does not work completely. A explicit p.flush() is needed to get the desired behaviour. ---------------------------------------------------------------------- >Comment By: Stefan Sonnenberg (sunmountain) Date: 2006-08-16 15:28 Message: Logged In: YES user_id=1575341 Sorry, that is not possible, because I work for a financial institution and the source can't be published. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-16 15:12 Message: Logged In: YES user_id=21627 I can't reproduce this, and I can't see anything in the Python source code that might be causing it. Can you provide a reproducable test case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539954&group_id=5470 From noreply at sourceforge.net Wed Aug 16 17:26:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 08:26:04 -0700 Subject: [ python-Bugs-1539954 ] Closing a pipe can lead to uncompleted command Message-ID: Bugs item #1539954, was opened at 2006-08-14 14:11 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539954&group_id=5470 Please note that this 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: Works For Me Priority: 5 Submitted By: Stefan Sonnenberg (sunmountain) Assigned to: Nobody/Anonymous (nobody) Summary: Closing a pipe can lead to uncompleted command Initial Comment: I'm using python version 2.3.3 (#0, Apr 22 2004, 11:33:00) [SunCC 5.5] under Solaris 9. I'm doing basically this: p = os.popen("cmd","w") p.write(cmd_string) p.close() Sometimes the command opened with popen does not work completely. A explicit p.flush() is needed to get the desired behaviour. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-16 17:26 Message: Logged In: YES user_id=21627 Ok, closing it as "works for me", then. Thanks for the report. ---------------------------------------------------------------------- Comment By: Stefan Sonnenberg (sunmountain) Date: 2006-08-16 15:28 Message: Logged In: YES user_id=1575341 Sorry, that is not possible, because I work for a financial institution and the source can't be published. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-16 15:12 Message: Logged In: YES user_id=21627 I can't reproduce this, and I can't see anything in the Python source code that might be causing it. Can you provide a reproducable test case? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1539954&group_id=5470 From noreply at sourceforge.net Wed Aug 16 17:30:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 08:30:33 -0700 Subject: [ python-Bugs-1534630 ] Python 2.5 svn crash in _elementtree.c Message-ID: Bugs item #1534630, was opened at 2006-08-04 17:29 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fredrik Lundh (effbot) Summary: Python 2.5 svn crash in _elementtree.c Initial Comment: /F's sourceforge screen scraper tool triggered a crash in _elementtree.c in the latest Python 2.5 svn. It seems that a Py_DECREF should probably be a Py_XDECREF unless there's some other logic bug I'm missing. Here's the patch if it's the former. ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2006-08-16 17:30 Message: Logged In: YES user_id=38376 Alright, I've finally identified the problem: you get this crash if you call the "data" method on a builder *before* you call any other method. E.g. bob = ET.TreeBuilder() bob.data("data") # <-- crash! bob.start("tag", {}) bob.end("tag") bob.close() In this case, self->last will point to Py_None, instead of an Element object, and self->last->text will thus be a mostly random pointer... Note that his cannot happen if you're using the Expat parser; the parser will raise a syntax error before calling any TreeBuilder method. This should be easy to fix (make treebuilder_handle_data return immediately if self->last == Py_None); I'll try getting this in before the code freeze. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2006-08-11 19:23 Message: Logged In: YES user_id=38376 I'm pretty sure this only happens if you're explicitly using the TreeBuilder class, which is a rather specialized use of ET. I'm also pretty sure that this is a cElementTree regression; I have a vague memory that I did some "optimizations" around 1.0.4 or 1.0.5 that might have caused this. I hope to find some time to look at this this weekend. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-11 17:30 Message: Logged In: YES user_id=33168 Yes, for all the reasons you mention. Also, I'm not sure that anyone other than /f can address this problem and I don't know when he will be able to fix it. I would very much prefer this be addressed prior to 2.5, but if it has to wait for 2.5.1 so be it. Also, I would guess this same problem is in the external version, so it's probably not a 'regression' either, even though this is a new module. Realize that there's still a month before release. So this is a non-issue if you can convince /f to fix it soon-ish. :-) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-11 14:42 Message: Logged In: YES user_id=12800 You might be right about the basic invariant problem, but why shouldn't it block release? Is your thinking that because it's a problem in an extension module (and a new and probably rarely used one at that)? It's definitely severe enough to hit people who use the module, not that it can't be fixed after the 2.5 release of course. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-11 06:21 Message: Logged In: YES user_id=33168 I don't think this patch will address the underlying problem. There are many DECREFs (and no XDECREFs) of last->text. It seems that the code believes there cannot be a NULL. Perhaps all the DECREFs of last->text should be XDECREF? I would really like this to get done for 2.5, but it shouldn't block release. Dropping priority. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&group_id=5470 From noreply at sourceforge.net Wed Aug 16 17:50:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 08:50:50 -0700 Subject: [ python-Bugs-1540529 ] cgi.py error on parsing/handling content-disposition Message-ID: Bugs item #1540529, was opened at 2006-08-15 06:31 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1540529&group_id=5470 Please note that this 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: Dirk Holtwick (holtwick) Assigned to: Nobody/Anonymous (nobody) Summary: cgi.py error on parsing/handling content-disposition Initial Comment: A header like this one containing a ";" and blanks in the content disposition fails: Content-Disposition: form-data; name="_media"; filename="Demo; 28.07.2006.jpg" The cause is, that the function parse_header() first splits the line by ";" and then begins to analize these parts. The part "filename" in our example is then split into two separate parts. I wrote a fix for the function parse_header(). It isn't still complete, because escaped '"' on the end of line are not respected, but in most cases it helps. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-16 11:50 Message: Logged In: YES user_id=764593 The test is good. The corner case is misses would also be a good test. I'm wondering whether a better fix might be to put parsing- around-quotes in a common library, and import it from there; these problems keep coming up, particularly in the web-related modules. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1540529&group_id=5470 From noreply at sourceforge.net Wed Aug 16 18:19:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 09:19:53 -0700 Subject: [ python-Bugs-1541420 ] tools and demo missing from windows Message-ID: Bugs item #1541420, was opened at 2006-08-16 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=1541420&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: tools and demo missing from windows Initial Comment: The windows distribution (I'm currently looking at 2.5b3) does not contain a Demo directory, and the Tools directory contains only five subdirectories (i18n, pynche, Scripts, versioncheck, webchecker) SVN Head lists 20 directories under Demo and 17 under Tools. At a first pass, all except tools/audiopy (Solaris specific) are relevant on Windows, and some tools (such as freeze, msi) even have windows-specific code. I've marked it 2.5 because consistency with other platforms seems like a bugfix, even if it does introduce new features to windows. (And note that it only adds new files that are not on the standard path, which should limit the risks.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541420&group_id=5470 From noreply at sourceforge.net Wed Aug 16 18:47:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 09:47:53 -0700 Subject: [ python-Bugs-1534630 ] Python 2.5 svn crash in _elementtree.c Message-ID: Bugs item #1534630, was opened at 2006-08-04 17:29 Message generated for change (Settings changed) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Fredrik Lundh (effbot) Summary: Python 2.5 svn crash in _elementtree.c Initial Comment: /F's sourceforge screen scraper tool triggered a crash in _elementtree.c in the latest Python 2.5 svn. It seems that a Py_DECREF should probably be a Py_XDECREF unless there's some other logic bug I'm missing. Here's the patch if it's the former. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2006-08-16 17:30 Message: Logged In: YES user_id=38376 Alright, I've finally identified the problem: you get this crash if you call the "data" method on a builder *before* you call any other method. E.g. bob = ET.TreeBuilder() bob.data("data") # <-- crash! bob.start("tag", {}) bob.end("tag") bob.close() In this case, self->last will point to Py_None, instead of an Element object, and self->last->text will thus be a mostly random pointer... Note that his cannot happen if you're using the Expat parser; the parser will raise a syntax error before calling any TreeBuilder method. This should be easy to fix (make treebuilder_handle_data return immediately if self->last == Py_None); I'll try getting this in before the code freeze. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2006-08-11 19:23 Message: Logged In: YES user_id=38376 I'm pretty sure this only happens if you're explicitly using the TreeBuilder class, which is a rather specialized use of ET. I'm also pretty sure that this is a cElementTree regression; I have a vague memory that I did some "optimizations" around 1.0.4 or 1.0.5 that might have caused this. I hope to find some time to look at this this weekend. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-11 17:30 Message: Logged In: YES user_id=33168 Yes, for all the reasons you mention. Also, I'm not sure that anyone other than /f can address this problem and I don't know when he will be able to fix it. I would very much prefer this be addressed prior to 2.5, but if it has to wait for 2.5.1 so be it. Also, I would guess this same problem is in the external version, so it's probably not a 'regression' either, even though this is a new module. Realize that there's still a month before release. So this is a non-issue if you can convince /f to fix it soon-ish. :-) ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-08-11 14:42 Message: Logged In: YES user_id=12800 You might be right about the basic invariant problem, but why shouldn't it block release? Is your thinking that because it's a problem in an extension module (and a new and probably rarely used one at that)? It's definitely severe enough to hit people who use the module, not that it can't be fixed after the 2.5 release of course. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-11 06:21 Message: Logged In: YES user_id=33168 I don't think this patch will address the underlying problem. There are many DECREFs (and no XDECREFs) of last->text. It seems that the code believes there cannot be a NULL. Perhaps all the DECREFs of last->text should be XDECREF? I would really like this to get done for 2.5, but it shouldn't block release. Dropping priority. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1534630&group_id=5470 From noreply at sourceforge.net Wed Aug 16 19:20:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 10:20:10 -0700 Subject: [ python-Bugs-1541420 ] tools and demo missing from windows Message-ID: Bugs item #1541420, was opened at 2006-08-16 16:19 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541420&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None >Priority: 8 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: tools and demo missing from windows Initial Comment: The windows distribution (I'm currently looking at 2.5b3) does not contain a Demo directory, and the Tools directory contains only five subdirectories (i18n, pynche, Scripts, versioncheck, webchecker) SVN Head lists 20 directories under Demo and 17 under Tools. At a first pass, all except tools/audiopy (Solaris specific) are relevant on Windows, and some tools (such as freeze, msi) even have windows-specific code. I've marked it 2.5 because consistency with other platforms seems like a bugfix, even if it does introduce new features to windows. (And note that it only adds new files that are not on the standard path, which should limit the risks.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541420&group_id=5470 From noreply at sourceforge.net Wed Aug 16 19:37:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 10:37:21 -0700 Subject: [ python-Feature Requests-1541463 ] Optimizations for cgi.FieldStorage methods Message-ID: Feature Requests item #1541463, was opened at 2006-08-16 13:37 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=1541463&group_id=5470 Please note that this 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: Bob Kline (bkline) Assigned to: Nobody/Anonymous (nobody) Summary: Optimizations for cgi.FieldStorage methods Initial Comment: Please add the following optimizations to the FieldStorage class in cgi.py: # ================================================= def keys(self): """Dictionary style keys() method.""" if self.list is None: raise TypeError, "not indexable" return {}.fromkeys([item.name for item in self.list]).keys() def __nonzero__(self): """Support for efficient test of instance""" return self.list and True or False # ================================================= The __nonzero__ method is new, and keys() method is a replacement for code which built the list of unique fields names by hand, and which took several orders of magnitude longer to perform. If you need me to post this as a patch against a certain version, let me know. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1541463&group_id=5470 From noreply at sourceforge.net Wed Aug 16 19:42:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 10:42:22 -0700 Subject: [ python-Feature Requests-1541463 ] Optimizations for cgi.FieldStorage methods Message-ID: Feature Requests item #1541463, was opened at 2006-08-16 13:37 Message generated for change (Settings changed) made by bkline You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1541463&group_id=5470 Please note that this 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: Bob Kline (bkline) >Assigned to: Georg Brandl (gbrandl) Summary: Optimizations for cgi.FieldStorage methods Initial Comment: Please add the following optimizations to the FieldStorage class in cgi.py: # ================================================= def keys(self): """Dictionary style keys() method.""" if self.list is None: raise TypeError, "not indexable" return {}.fromkeys([item.name for item in self.list]).keys() def __nonzero__(self): """Support for efficient test of instance""" return self.list and True or False # ================================================= The __nonzero__ method is new, and keys() method is a replacement for code which built the list of unique fields names by hand, and which took several orders of magnitude longer to perform. If you need me to post this as a patch against a certain version, let me know. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1541463&group_id=5470 From noreply at sourceforge.net Wed Aug 16 19:52:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 10:52:24 -0700 Subject: [ python-Feature Requests-1541463 ] Optimizations for cgi.FieldStorage methods Message-ID: Feature Requests item #1541463, was opened at 2006-08-16 13:37 Message generated for change (Comment added) made by bkline You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1541463&group_id=5470 Please note that this 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: Bob Kline (bkline) Assigned to: Georg Brandl (gbrandl) Summary: Optimizations for cgi.FieldStorage methods Initial Comment: Please add the following optimizations to the FieldStorage class in cgi.py: # ================================================= def keys(self): """Dictionary style keys() method.""" if self.list is None: raise TypeError, "not indexable" return {}.fromkeys([item.name for item in self.list]).keys() def __nonzero__(self): """Support for efficient test of instance""" return self.list and True or False # ================================================= The __nonzero__ method is new, and keys() method is a replacement for code which built the list of unique fields names by hand, and which took several orders of magnitude longer to perform. If you need me to post this as a patch against a certain version, let me know. ---------------------------------------------------------------------- >Comment By: Bob Kline (bkline) Date: 2006-08-16 13:52 Message: Logged In: YES user_id=291529 I didn't realize this interface would strip leading blanks from lines. Patch submitted to get around this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1541463&group_id=5470 From noreply at sourceforge.net Wed Aug 16 20:25:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 11:25:51 -0700 Subject: [ python-Feature Requests-1538778 ] pyo's are not overwritten by different optimization levels Message-ID: Feature Requests item #1538778, was opened at 2006-08-11 11:23 Message generated for change (Comment added) made by abadger1999 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1538778&group_id=5470 Please note that this 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: Toshio Kuratomi (abadger1999) Assigned to: Nobody/Anonymous (nobody) Summary: pyo's are not overwritten by different optimization levels Initial Comment: If I invoke "python -OO" on a set of files, python creates a set of .pyo files. If I then realize this is an incredibly stupid thing to do because it removes the docstrings from the output and this program requires those docstrings python does not give me a method of overwriting the generated .pyos. I anticipated that running "python -O" would detect that the already generated .pyos were created in a different optimixation level and overwrite them with new .pyos. Barring that, I expected there to be a command line switch to tell python to overwrite the previously generated .pyo cache files. Finding neither, I realized that the only way to recover docstrings for people using python -O was to rm all the generated .pyo files. This seems like a bug or a missing feature. ---------------------------------------------------------------------- >Comment By: Toshio Kuratomi (abadger1999) Date: 2006-08-16 14:25 Message: Logged In: YES user_id=944205 Thanks. PEP 304 is a bit different. It is specifying the ability to read and write bytecode to a different directory structure while this is specifying that bytecode, once written is taken as canoncical even when options on the python commandline would change the bytecode that is written. Another solution in addition to those above would be writing files with different extensions for different optimization levels although this seems worse than either of the other two changes. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-16 09:18 Message: Logged In: YES user_id=21627 This is a feature request; classifying it as such. See also PEP 304 (notice it has been withdrawn). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1538778&group_id=5470 From noreply at sourceforge.net Wed Aug 16 22:44:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 13:44:04 -0700 Subject: [ python-Bugs-780714 ] infinite __str__ recursion in thread causes seg fault Message-ID: Bugs item #780714, was opened at 2003-07-31 08:37 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: Stefan Gregory (stefan_gregory) Assigned to: Nobody/Anonymous (nobody) Summary: infinite __str__ recursion in thread causes seg fault Initial Comment: The following code reliably produces a segmentation fault under Solaris8 in Python2.3, Python2.2, Python2.1.3 and Python1.5. It produces a Bus Error when run on Python2.2 under OSX. Clearly it should produce a Python RuntimeError. import thread, time class Frog: def __str__(self): return str(self) f = Frog() thread.start_new_thread(str,(f,)) time.sleep(1000) This problem manifests in scenarios such as when you have 2 publishing objects (such as HTMLgen objects) A and B and you put A inside B and B inside A and each objects __str__ method calls its childrens __str__ methods and voila! (I hope this might be the reason my Zope server has been intermitently crashing for the past year or so though I have not found any recursive structures yet.) With Python2.3 gdb reports: vgetargskeywords (args=0x1bdaf0, keywords=0x0, format=0xd2579 "0:str", kwlist=0xf7b4c, p_va=0xfed0C02c) at Python/getargs.c:1167 Though with Python2.1 it dies at line 330 in getargs.c. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-08-16 07:42 Message: Logged In: YES user_id=341410 >>> import sys >>> sys.setrecursionlimit(10000) >>> class foo: ... def __str__(self): ... return str(self) ... >>> import threading >>> threading.Thread(target=foo().__str__).start() Kills 2.3, 2.4, and 2.5 on Windows, and 2.3 and 2.4 on linux (I can't test 2.5 on linux). Running in the main thread on Windows doesn't seem to be a big deal: >>> import sys >>> sys.setrecursionlimit(10000) >>> class foo: ... def __str__(self): ... return str(self) ... >>> try: ... str(foo()) ... except Exception, why: ... print why ... Stack overflow >>> Note that the above crashes 2.3 and 2.4 on Linux. This is still a bug, at least in maintenance on 2.4. Suggested reopen. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-08-14 02:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-30 11:16 Message: Logged In: YES user_id=849994 Under 2.5, I get a runtime error now, so this might be fixed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-05 19:22 Message: Logged In: YES user_id=357491 Forgot to mention that Modules/threadmodule.c has thread_PyThread_start_new_thread which uses Python/ thread_*.h's PyThread_start_new_thread for executing threads; the '*' is replaced with the threading library used on your platform. OS X should use thread_pthread.h (I think). ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-08-05 19:19 Message: Logged In: YES user_id=357491 If you run ``str(Frog())`` instead of a bunch of threads you do get a RuntimeError. Looks like this bus error has something to do with thread.start_new_thread and not 'str'. It might be that since it runs using pthreads it does not have the built-in recursion limit check that the Python interpreter has. Anyone with more experience with the 'thread' module have any ideas? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780714&group_id=5470 From noreply at sourceforge.net Wed Aug 16 22:59:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 13:59:15 -0700 Subject: [ python-Bugs-1541566 ] bug in python 2.4.3 for windows? Message-ID: Bugs item #1541566, was opened at 2006-08-16 20: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=1541566&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: tinkiwinky (tinkiwinky) Assigned to: Nobody/Anonymous (nobody) Summary: bug in python 2.4.3 for windows? Initial Comment: y = ["halo:lol","ich:bin","wir:wareum","galopp:kufladen"] for i in y: z = i.split(":")[0] if z is "wir": print z, "is wir" else: print z, "is not wir" the output from this include: "wir is not wir" I am using python 2.4.3 on windows xp sp2 german ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541566&group_id=5470 From noreply at sourceforge.net Wed Aug 16 23:07:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 14:07:28 -0700 Subject: [ python-Bugs-1541566 ] bug in python 2.4.3 for windows? Message-ID: Bugs item #1541566, was opened at 2006-08-16 20:59 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541566&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: tinkiwinky (tinkiwinky) Assigned to: Nobody/Anonymous (nobody) Summary: bug in python 2.4.3 for windows? Initial Comment: y = ["halo:lol","ich:bin","wir:wareum","galopp:kufladen"] for i in y: z = i.split(":")[0] if z is "wir": print z, "is wir" else: print z, "is not wir" the output from this include: "wir is not wir" I am using python 2.4.3 on windows xp sp2 german ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-16 21:07 Message: Logged In: YES user_id=849994 Don't use "is" for string comparison. It compares object identity, and while this may work in some cases, it does not in most. Use "==" instead. Closing as Invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541566&group_id=5470 From noreply at sourceforge.net Wed Aug 16 23:52:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 14:52:06 -0700 Subject: [ python-Bugs-1530142 ] Mac Universal Build of Python confuses distutils Message-ID: Bugs item #1530142, was opened at 2006-07-28 16:02 Message generated for change (Comment added) made by richard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530142&group_id=5470 Please note that this 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: Richard Jones (richard) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: Mac Universal Build of Python confuses distutils Initial Comment: I'm sorry I can't provide a fully-detailed report here, but I'm not in a position to be able to reproduce the problem. In short, I installed the Universal build of Python 2.4.3 for the Mac downloaded from: http://pythonmac.org/packages/py24-fat/index.html I don't know whether this is the same as the download from: http://www.python.org/download/releases/2.4.3/ Once installed, I attempted to build ctypes. The build failed due to an assembly error (unknown instruction). I'm not familiar with the PPC or x86 assembler code so couldn't do a thorough analysis. I needed Python2.4 to work, so I found an older PPC-only installer and used that. ---------------------------------------------------------------------- >Comment By: Richard Jones (richard) Date: 2006-08-17 07:52 Message: Logged In: YES user_id=6405 I successfully built ctypes on PPC OSX using a non-universal build. Also, I wasn't running on x86 OSX so it shouldn't have tried to build that. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-08-16 23:25 Message: Logged In: YES user_id=21627 This might be a ctypes limitation: it might be that ctypes doesn't support x86-OSX (atleast in this release). ---------------------------------------------------------------------- Comment By: Richard Jones (richard) Date: 2006-07-28 16:47 Message: Logged In: YES user_id=6405 0.9.9.6 ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-07-28 16:28 Message: Logged In: YES user_id=580910 Which version of ctypes did you try to build? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1530142&group_id=5470 From noreply at sourceforge.net Thu Aug 17 01:39:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 16:39:59 -0700 Subject: [ python-Bugs-1541642 ] Compiler command percent-sign causes format string error Message-ID: Bugs item #1541642, was opened at 2006-08-16 18: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=1541642&group_id=5470 Please note that this 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: Matthew Cowles (mdcowles) Assigned to: Nobody/Anonymous (nobody) Summary: Compiler command percent-sign causes format string error Initial Comment: [From a question posted to python-help] Using Sun's compiler, distutils generates a command line with a percent-sign in it: cc -DNDEBUG -xO3 -xtarget=native -xbuiltin=%all -xdepend=yes - xlibmil -xlibmopt -xstrconst -Xa -I/opt/pkg/include/db4 -I/usr/ include -I/opt/pkg/include -xcode=pic32 -OPT:Olimit=0 -I. -I/opt/ pkg.obj/lang/python24/work.e450/Python-2.4.3/./Include -I/opt/ pkg/include -I/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/ Include -I/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3 -c / opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Modules/ structmodule.c -o build/temp.solaris-2.10-sun4u-2.4/structmodule.o It seems that the percent-sign in "-xbuiltin=%all" isn't escaped when distutils goes to print the line and a format string error occurs: File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/log.py", line 23, in _log print msg % args TypeError: not enough arguments for format string *** Error code 1 Here's the full traceback: running build running build_ext INFO: Can't locate Tcl/Tk libs and/or headers building 'struct' extension Traceback (most recent call last): File "./setup.py", line 1105, in ? main() File "./setup.py", line 1099, in main scripts = ['Tools/scripts/pydoc2.4', File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/core.py", line 149, in setup dist.run_commands() File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/dist.py", line 966, in run_command cmd_obj.run() File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/dist.py", line 966, in run_command cmd_obj.run() File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/command/build_ext.py", line 279, in run self.build_extensions() File "./setup.py", line 179, in build_extensions build_ext.build_extensions(self) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/command/build_ext.py", line 405, in build_extensions self.build_extension(ext) File "./setup.py", line 184, in build_extension build_ext.build_extension(self, ext) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/command/build_ext.py", line 470, in build_extension depends=ext.depends) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/ccompiler.py", line 699, in compile self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/unixccompiler.py", line 112, in _compile self.spawn(self.compiler_so + cc_args + [src, '-o', obj] + File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/ccompiler.py", line 1040, in spawn spawn (cmd, dry_run=self.dry_run) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/spawn.py", line 37, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/spawn.py", line 122, in _spawn_posix log.info(string.join(cmd, ' ')) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/log.py", line 33, in info self._log(INFO, msg, args) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/log.py", line 23, in _log print msg % args TypeError: not enough arguments for format string *** Error code 1 (I'm posting this for the person who originally ran into the error and asked about it on python-help.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541642&group_id=5470 From noreply at sourceforge.net Thu Aug 17 02:48:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 17:48:58 -0700 Subject: [ python-Bugs-1541671 ] bsddb can't use unicode filenames Message-ID: Bugs item #1541671, was opened at 2006-08-17 00:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541671&group_id=5470 Please note that this 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: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb can't use unicode filenames Initial Comment: with Python 2.5b3, Here is an attempt to use a unicode filename with bsddb: >>> dbe = db.DBEnv() >>> dbe.open(u'\u03b3\u03bb\u03ce\u03c3\u03c32', db.DB_CREATE | db.DB_INIT_MPOOL) Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-4: ordinal not in range(128) This is on Windows XP. Here are some indications that the underlying SleepyCat library ought to be able to do the right thing here: http://www.sleepycat.com/xmldocs/ref/build_win/unicode.html http://www.sleepycat.com/update/4.3.29/if.4.3.29.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541671&group_id=5470 From noreply at sourceforge.net Thu Aug 17 03:13:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 18:13:28 -0700 Subject: [ python-Bugs-1541682 ] Incorrect example calls to PyObject_SetItem Message-ID: Bugs item #1541682, was opened at 2006-08-17 11:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541682&group_id=5470 Please note that this 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: John Machin (sjmachin) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect example calls to PyObject_SetItem Initial Comment: http://docs.python.org/dev/api/refcountDetails.html Example acts as though the 2nd arg to PyObject_SetItem is a C int (as it is for the List and Sequence varieties) -- it is in fact a (PyObject *) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541682&group_id=5470 From noreply at sourceforge.net Thu Aug 17 03:51:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 18:51:00 -0700 Subject: [ python-Bugs-1541697 ] Recently introduced sgmllib regexp bug hangs Python Message-ID: Bugs item #1541697, was opened at 2006-08-17 02: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=1541697&group_id=5470 Please note that this 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: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Recently introduced sgmllib regexp bug hangs Python Initial Comment: Looks like revision 47154 introduced a regexp that hangs Python (Ctrl-C won't kill the process, CPU usage sits near 100%) under some circumstances. A test case is attached (sgmllib.html and hang_sgmllib.py). The problem isn't seen if you read the whole file (or nearly the whole file) at once. But that doesn't make it a non-bug, AFAICS. I'm not sure what the problem is, but presumably the relevant part of the patch is this: +starttag = re.compile(r'<[a-zA-Z][-_.:a-zA-Z0-9]*\s*(' + r'\s*([a-zA-Z_][-:.a-zA-Z_0-9]*)(\s*=\s*' + r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~@]' + r'[][\-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~\'"@]*(?=[\s>/<])))?' + r')*\s*/?\s*(?=[<>])') The patch attached to bug 1515142 (also from Sam Ruby -- claims to fix a regression introduced by his recent sgmllib patches, and has not yet been applied) does NOT fix the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&group_id=5470 From noreply at sourceforge.net Thu Aug 17 05:05:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 16 Aug 2006 20:05:57 -0700 Subject: [ python-Bugs-1541697 ] Recently introduced sgmllib regexp bug hangs Python Message-ID: Bugs item #1541697, was opened at 2006-08-16 18:51 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&group_id=5470 Please note that this 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: 8 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Recently introduced sgmllib regexp bug hangs Python Initial Comment: Looks like revision 47154 introduced a regexp that hangs Python (Ctrl-C won't kill the process, CPU usage sits near 100%) under some circumstances. A test case is attached (sgmllib.html and hang_sgmllib.py). The problem isn't seen if you read the whole file (or nearly the whole file) at once. But that doesn't make it a non-bug, AFAICS. I'm not sure what the problem is, but presumably the relevant part of the patch is this: +starttag = re.compile(r'<[a-zA-Z][-_.:a-zA-Z0-9]*\s*(' + r'\s*([a-zA-Z_][-:.a-zA-Z_0-9]*)(\s*=\s*' + r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~@]' + r'[][\-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~\'"@]*(?=[\s>/<])))?' + r')*\s*/?\s*(?=[<>])') The patch attached to bug 1515142 (also from Sam Ruby -- claims to fix a regression introduced by his recent sgmllib patches, and has not yet been applied) does NOT fix the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&group_id=5470 From noreply at sourceforge.net Thu Aug 17 16:21:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 07:21:13 -0700 Subject: [ python-Bugs-1542016 ] inconsistency in PCALL conditional code in ceval.c Message-ID: Bugs item #1542016, was opened at 2006-08-17 16:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542016&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Santiago Gala (sgala) Assigned to: Nobody/Anonymous (nobody) Summary: inconsistency in PCALL conditional code in ceval.c Initial Comment: While there are macros to profile PCALL_POP, the reporting of it via sys.callstats() is broken. This patch solves it. Index: Python/ceval.c =================================================================== --- Python/ceval.c (revisi?n: 51339) +++ Python/ceval.c (copia de trabajo) @@ -186,10 +186,10 @@ PyObject * PyEval_GetCallStats(PyObject *self) { - return Py_BuildValue("iiiiiiiiii", + return Py_BuildValue("iiiiiiiiiii", pcall[0], pcall[1], pcall[2], pcall[3], pcall[4], pcall[5], pcall[6], pcall[7], - pcall[8], pcall[9]); + pcall[8], pcall[9], pcall[10]); } #else #define PCALL(O) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542016&group_id=5470 From noreply at sourceforge.net Thu Aug 17 16:53:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 07:53:11 -0700 Subject: [ python-Bugs-1528802 ] Turkish Character Message-ID: Bugs item #1528802, was opened at 2006-07-26 09:05 Message generated for change (Comment added) made by sgala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 Please note that this 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: 6 Submitted By: Ahmet Bi?kinler (ahmetbiskinler) Assigned to: M.-A. Lemburg (lemburg) Summary: Turkish Character Initial Comment: >>> print "May?s".upper() >>> MAY?S >>> import locale >>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254') >>> print "May?s".upper() >>> MAY?S >>> print "???i???".upper() >>> ???I??? MAY?S should be MAYIS ???I??? should be ??????I but >>> "May?s".upper() >>> "MAYIS" is right ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 16:53 Message: Logged In: YES user_id=178886 The behaviour of python in this area is confusing. See a session with my Spanish keyboard: >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ? >>> print len(u"?") 1 >>> print u"?".upper() ? >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) I guess this is what is happening to the reporter. This violates the least surprising behavior principle in so many different ways that it hurts. Can anybody make sense of it? ---------------------------------------------------------------------- Comment By: Ahmet Bi?kinler (ahmetbiskinler) Date: 2006-08-11 10:10 Message: Logged In: YES user_id=1481281 What happened? Is it solved? How is it going? What is the final step? ...? ...? Could you please give me some information about the bug please? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 From noreply at sourceforge.net Thu Aug 17 16:59:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 07:59:06 -0700 Subject: [ python-Bugs-1528802 ] Turkish Character Message-ID: Bugs item #1528802, was opened at 2006-07-26 09:05 Message generated for change (Comment added) made by sgala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 Please note that this 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: 6 Submitted By: Ahmet Bi?kinler (ahmetbiskinler) Assigned to: M.-A. Lemburg (lemburg) Summary: Turkish Character Initial Comment: >>> print "May?s".upper() >>> MAY?S >>> import locale >>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254') >>> print "May?s".upper() >>> MAY?S >>> print "???i???".upper() >>> ???I??? MAY?S should be MAYIS ???I??? should be ??????I but >>> "May?s".upper() >>> "MAYIS" is right ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 16:59 Message: Logged In: YES user_id=178886 (I tested it in 2.5rc1), 2.4 gives >>> str(u"?") '\xc3\xa1' instead of the exception ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 16:53 Message: Logged In: YES user_id=178886 The behaviour of python in this area is confusing. See a session with my Spanish keyboard: >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ? >>> print len(u"?") 1 >>> print u"?".upper() ? >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) I guess this is what is happening to the reporter. This violates the least surprising behavior principle in so many different ways that it hurts. Can anybody make sense of it? ---------------------------------------------------------------------- Comment By: Ahmet Bi?kinler (ahmetbiskinler) Date: 2006-08-11 10:10 Message: Logged In: YES user_id=1481281 What happened? Is it solved? How is it going? What is the final step? ...? ...? Could you please give me some information about the bug please? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 From noreply at sourceforge.net Thu Aug 17 17:03:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 08:03:33 -0700 Subject: [ python-Bugs-1528802 ] Turkish Character Message-ID: Bugs item #1528802, was opened at 2006-07-26 07:05 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 Please note that this 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: 6 Submitted By: Ahmet Bi?kinler (ahmetbiskinler) Assigned to: M.-A. Lemburg (lemburg) Summary: Turkish Character Initial Comment: >>> print "May?s".upper() >>> MAY?S >>> import locale >>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254') >>> print "May?s".upper() >>> MAY?S >>> print "???i???".upper() >>> ???I??? MAY?S should be MAYIS ???I??? should be ??????I but >>> "May?s".upper() >>> "MAYIS" is right ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 15:03 Message: Logged In: YES user_id=849994 sgala: it looks like your console sends UTF-8 encoded text. >>> print "?" ? print is just printing out a byte string consisting of two bytes, which your console displays as accent-a. >>> print len("?") 2 A UTF-8-encoded string containing an accented a has two bytes. >>> print "?".upper() ? str.upper() doesn't take locale into account, so the accented a has no uppercase version defined. >>> str("?") '\xc3\xa1' str() applied to a byte string returns that byte string. Since return values from functions are printed by the interactive interpreter using repr() first, you get this representation (which you could also get from "print repr('a')".) >>> print u"?" ? That's also okay. Python knows the terminal encoding and properly translates the byte string to a unicode string of one character. On printout, it converts it to a UTF-8 string again, which your terminal displays correctly. >>> print len(u"?") 1 Since your two-byte-UTF-8 sequence is converted to a unicode character, the length of this unicode string is 1. >>> print u"?".upper() ? There are comprehensive capitalization tables available for unicode. >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) Applying str() to a unicode string must convert it to a byte string. If you don't specify an encoding, the default encoding is "ascii", which can't encode the accented a. Use "a".encode("utf-8"). ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 14:59 Message: Logged In: YES user_id=178886 (I tested it in 2.5rc1), 2.4 gives >>> str(u"?") '\xc3\xa1' instead of the exception ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 14:53 Message: Logged In: YES user_id=178886 The behaviour of python in this area is confusing. See a session with my Spanish keyboard: >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ? >>> print len(u"?") 1 >>> print u"?".upper() ? >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) I guess this is what is happening to the reporter. This violates the least surprising behavior principle in so many different ways that it hurts. Can anybody make sense of it? ---------------------------------------------------------------------- Comment By: Ahmet Bi?kinler (ahmetbiskinler) Date: 2006-08-11 08:10 Message: Logged In: YES user_id=1481281 What happened? Is it solved? How is it going? What is the final step? ...? ...? Could you please give me some information about the bug please? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 From noreply at sourceforge.net Thu Aug 17 17:04:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 08:04:27 -0700 Subject: [ python-Bugs-1528802 ] Turkish Character Message-ID: Bugs item #1528802, was opened at 2006-07-26 09:05 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 Please note that this 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: 6 Submitted By: Ahmet Bi?kinler (ahmetbiskinler) Assigned to: M.-A. Lemburg (lemburg) Summary: Turkish Character Initial Comment: >>> print "May?s".upper() >>> MAY?S >>> import locale >>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254') >>> print "May?s".upper() >>> MAY?S >>> print "???i???".upper() >>> ???I??? MAY?S should be MAYIS ???I??? should be ??????I but >>> "May?s".upper() >>> "MAYIS" is right ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-17 17:04 Message: Logged In: YES user_id=38388 String upper and lower conversion are locale dependent and implemented by the underlying libc, whereas Unicode upper/lower conversion is not and only depends on the Unicode character database. OTOH, there are special cases where the standard Unicode upper/lower mapping is no what you might expect, since the database only provides a single mapping and is not context aware. There's nothing we can do if the libc is broken in some respect. As for the extended case mapping support in Unicode: patches are welcome. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 17:03 Message: Logged In: YES user_id=849994 sgala: it looks like your console sends UTF-8 encoded text. >>> print "?" ? print is just printing out a byte string consisting of two bytes, which your console displays as accent-a. >>> print len("?") 2 A UTF-8-encoded string containing an accented a has two bytes. >>> print "?".upper() ? str.upper() doesn't take locale into account, so the accented a has no uppercase version defined. >>> str("?") '\xc3\xa1' str() applied to a byte string returns that byte string. Since return values from functions are printed by the interactive interpreter using repr() first, you get this representation (which you could also get from "print repr('a')".) >>> print u"?" ? That's also okay. Python knows the terminal encoding and properly translates the byte string to a unicode string of one character. On printout, it converts it to a UTF-8 string again, which your terminal displays correctly. >>> print len(u"?") 1 Since your two-byte-UTF-8 sequence is converted to a unicode character, the length of this unicode string is 1. >>> print u"?".upper() ? There are comprehensive capitalization tables available for unicode. >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) Applying str() to a unicode string must convert it to a byte string. If you don't specify an encoding, the default encoding is "ascii", which can't encode the accented a. Use "a".encode("utf-8"). ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 16:59 Message: Logged In: YES user_id=178886 (I tested it in 2.5rc1), 2.4 gives >>> str(u"?") '\xc3\xa1' instead of the exception ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 16:53 Message: Logged In: YES user_id=178886 The behaviour of python in this area is confusing. See a session with my Spanish keyboard: >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ? >>> print len(u"?") 1 >>> print u"?".upper() ? >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) I guess this is what is happening to the reporter. This violates the least surprising behavior principle in so many different ways that it hurts. Can anybody make sense of it? ---------------------------------------------------------------------- Comment By: Ahmet Bi?kinler (ahmetbiskinler) Date: 2006-08-11 10:10 Message: Logged In: YES user_id=1481281 What happened? Is it solved? How is it going? What is the final step? ...? ...? Could you please give me some information about the bug please? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 From noreply at sourceforge.net Thu Aug 17 17:08:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 08:08:39 -0700 Subject: [ python-Bugs-1528802 ] Turkish Character Message-ID: Bugs item #1528802, was opened at 2006-07-26 07:05 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 Please note that this 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: 6 Submitted By: Ahmet Bi?kinler (ahmetbiskinler) Assigned to: M.-A. Lemburg (lemburg) Summary: Turkish Character Initial Comment: >>> print "May?s".upper() >>> MAY?S >>> import locale >>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254') >>> print "May?s".upper() >>> MAY?S >>> print "???i???".upper() >>> ???I??? MAY?S should be MAYIS ???I??? should be ??????I but >>> "May?s".upper() >>> "MAYIS" is right ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 15:08 Message: Logged In: YES user_id=849994 Using Unicode strings, the OP's example works. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-17 15:04 Message: Logged In: YES user_id=38388 String upper and lower conversion are locale dependent and implemented by the underlying libc, whereas Unicode upper/lower conversion is not and only depends on the Unicode character database. OTOH, there are special cases where the standard Unicode upper/lower mapping is no what you might expect, since the database only provides a single mapping and is not context aware. There's nothing we can do if the libc is broken in some respect. As for the extended case mapping support in Unicode: patches are welcome. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 15:03 Message: Logged In: YES user_id=849994 sgala: it looks like your console sends UTF-8 encoded text. >>> print "?" ? print is just printing out a byte string consisting of two bytes, which your console displays as accent-a. >>> print len("?") 2 A UTF-8-encoded string containing an accented a has two bytes. >>> print "?".upper() ? str.upper() doesn't take locale into account, so the accented a has no uppercase version defined. >>> str("?") '\xc3\xa1' str() applied to a byte string returns that byte string. Since return values from functions are printed by the interactive interpreter using repr() first, you get this representation (which you could also get from "print repr('a')".) >>> print u"?" ? That's also okay. Python knows the terminal encoding and properly translates the byte string to a unicode string of one character. On printout, it converts it to a UTF-8 string again, which your terminal displays correctly. >>> print len(u"?") 1 Since your two-byte-UTF-8 sequence is converted to a unicode character, the length of this unicode string is 1. >>> print u"?".upper() ? There are comprehensive capitalization tables available for unicode. >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) Applying str() to a unicode string must convert it to a byte string. If you don't specify an encoding, the default encoding is "ascii", which can't encode the accented a. Use "a".encode("utf-8"). ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 14:59 Message: Logged In: YES user_id=178886 (I tested it in 2.5rc1), 2.4 gives >>> str(u"?") '\xc3\xa1' instead of the exception ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 14:53 Message: Logged In: YES user_id=178886 The behaviour of python in this area is confusing. See a session with my Spanish keyboard: >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ? >>> print len(u"?") 1 >>> print u"?".upper() ? >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) I guess this is what is happening to the reporter. This violates the least surprising behavior principle in so many different ways that it hurts. Can anybody make sense of it? ---------------------------------------------------------------------- Comment By: Ahmet Bi?kinler (ahmetbiskinler) Date: 2006-08-11 08:10 Message: Logged In: YES user_id=1481281 What happened? Is it solved? How is it going? What is the final step? ...? ...? Could you please give me some information about the bug please? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 From noreply at sourceforge.net Thu Aug 17 17:21:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 08:21:08 -0700 Subject: [ python-Bugs-1542051 ] Exceptions don't call _PyObject_GC_UNTRACK(self) Message-ID: Bugs item #1542051, was opened at 2006-08-17 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=1542051&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Žiga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Exceptions don't call _PyObject_GC_UNTRACK(self) Initial Comment: If I understand the GC rules correctly, BaseException and its subclasses should call _PyObject_GC_UNTRACK in their tp_dealloc methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542051&group_id=5470 From noreply at sourceforge.net Thu Aug 17 17:23:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 08:23:31 -0700 Subject: [ python-Bugs-1541642 ] Compiler command percent-sign causes format string error Message-ID: Bugs item #1541642, was opened at 2006-08-16 18:39 Message generated for change (Settings changed) made by mdcowles You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541642&group_id=5470 Please note that this 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: Deleted >Resolution: Duplicate Priority: 5 Submitted By: Matthew Cowles (mdcowles) Assigned to: Nobody/Anonymous (nobody) Summary: Compiler command percent-sign causes format string error Initial Comment: [From a question posted to python-help] Using Sun's compiler, distutils generates a command line with a percent-sign in it: cc -DNDEBUG -xO3 -xtarget=native -xbuiltin=%all -xdepend=yes - xlibmil -xlibmopt -xstrconst -Xa -I/opt/pkg/include/db4 -I/usr/ include -I/opt/pkg/include -xcode=pic32 -OPT:Olimit=0 -I. -I/opt/ pkg.obj/lang/python24/work.e450/Python-2.4.3/./Include -I/opt/ pkg/include -I/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/ Include -I/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3 -c / opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Modules/ structmodule.c -o build/temp.solaris-2.10-sun4u-2.4/structmodule.o It seems that the percent-sign in "-xbuiltin=%all" isn't escaped when distutils goes to print the line and a format string error occurs: File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/log.py", line 23, in _log print msg % args TypeError: not enough arguments for format string *** Error code 1 Here's the full traceback: running build running build_ext INFO: Can't locate Tcl/Tk libs and/or headers building 'struct' extension Traceback (most recent call last): File "./setup.py", line 1105, in ? main() File "./setup.py", line 1099, in main scripts = ['Tools/scripts/pydoc2.4', File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/core.py", line 149, in setup dist.run_commands() File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/dist.py", line 966, in run_command cmd_obj.run() File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/command/build.py", line 112, in run self.run_command(cmd_name) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/cmd.py", line 333, in run_command self.distribution.run_command(command) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/dist.py", line 966, in run_command cmd_obj.run() File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/command/build_ext.py", line 279, in run self.build_extensions() File "./setup.py", line 179, in build_extensions build_ext.build_extensions(self) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/command/build_ext.py", line 405, in build_extensions self.build_extension(ext) File "./setup.py", line 184, in build_extension build_ext.build_extension(self, ext) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/command/build_ext.py", line 470, in build_extension depends=ext.depends) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/ccompiler.py", line 699, in compile self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/unixccompiler.py", line 112, in _compile self.spawn(self.compiler_so + cc_args + [src, '-o', obj] + File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/ccompiler.py", line 1040, in spawn spawn (cmd, dry_run=self.dry_run) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/spawn.py", line 37, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/spawn.py", line 122, in _spawn_posix log.info(string.join(cmd, ' ')) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/log.py", line 33, in info self._log(INFO, msg, args) File "/opt/pkg.obj/lang/python24/work.e450/Python-2.4.3/Lib/ distutils/log.py", line 23, in _log print msg % args TypeError: not enough arguments for format string *** Error code 1 (I'm posting this for the person who originally ran into the error and asked about it on python-help.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541642&group_id=5470 From noreply at sourceforge.net Thu Aug 17 20:37:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 11:37:11 -0700 Subject: [ python-Bugs-1542166 ] global variable: multiple id()-addresses Message-ID: Bugs item #1542166, was opened at 2006-08-17 14: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=1542166&group_id=5470 Please note that this 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: Frank R. Schaefer (fschaef) Assigned to: Nobody/Anonymous (nobody) Summary: global variable: multiple id()-addresses Initial Comment: The **attachment** contains an example where one single global variable appears at two different positions when applying the 'id(...)' function. The following files are attached: core.py: contains the definition of the global variable, two example functions, and a minimal class definition. test.py: a test program displaying that the global variable in core.py has two addresses. result.txt: the output of the test.py procedure. In practical this means that a variable 'my_module.global_var' may refer to two different objects! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542166&group_id=5470 From noreply at sourceforge.net Thu Aug 17 20:54:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 11:54:16 -0700 Subject: [ python-Bugs-1542166 ] global variable: multiple id()-addresses Message-ID: Bugs item #1542166, was opened at 2006-08-17 18:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542166&group_id=5470 Please note that this 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: Frank R. Schaefer (fschaef) Assigned to: Nobody/Anonymous (nobody) Summary: global variable: multiple id()-addresses Initial Comment: The **attachment** contains an example where one single global variable appears at two different positions when applying the 'id(...)' function. The following files are attached: core.py: contains the definition of the global variable, two example functions, and a minimal class definition. test.py: a test program displaying that the global variable in core.py has two addresses. result.txt: the output of the test.py procedure. In practical this means that a variable 'my_module.global_var' may refer to two different objects! ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 18:54 Message: Logged In: YES user_id=849994 In not_so_simple(), you *reassign* global_var. That means that it is bound to a different object afterwards. The name "global_var" you imported into the test module, however, is bound to the original global_var object, and this binding will not change. If that's not what you want, you'll have to do "import core" and refer to "core.global_var". Additionally, let me point out that using "global" to declare a name as global in a function that does not reassign that name is unnecessary. Closing as Invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542166&group_id=5470 From noreply at sourceforge.net Thu Aug 17 20:55:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 11:55:25 -0700 Subject: [ python-Bugs-1542051 ] Exceptions don't call _PyObject_GC_UNTRACK(self) Message-ID: Bugs item #1542051, was opened at 2006-08-17 15:21 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542051&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Submitted By: Žiga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: Exceptions don't call _PyObject_GC_UNTRACK(self) Initial Comment: If I understand the GC rules correctly, BaseException and its subclasses should call _PyObject_GC_UNTRACK in their tp_dealloc methods. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542051&group_id=5470 From noreply at sourceforge.net Thu Aug 17 20:58:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 11:58:29 -0700 Subject: [ python-Bugs-1528802 ] Turkish Character Message-ID: Bugs item #1528802, was opened at 2006-07-26 09:05 Message generated for change (Comment added) made by sgala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 Please note that this 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: 6 Submitted By: Ahmet Bi?kinler (ahmetbiskinler) Assigned to: M.-A. Lemburg (lemburg) Summary: Turkish Character Initial Comment: >>> print "May?s".upper() >>> MAY?S >>> import locale >>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254') >>> print "May?s".upper() >>> MAY?S >>> print "???i???".upper() >>> ???I??? MAY?S should be MAYIS ???I??? should be ??????I but >>> "May?s".upper() >>> "MAYIS" is right ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 20:58 Message: Logged In: YES user_id=178886 Idle from 2.5rc1 (svn today) produces a different result than console (with my default, utf-8, encoding): IDLE 1.2c1 >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ?? >>> print len(u"?") 2 >>> print u"?".upper() ?? >>> str(u"?") Traceback (most recent call last): File "", line 1, in str(u"?") UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128) Again, IDLE 1.1.3 (python 2.4.3) produces a different result: IDLE 1.1.3 >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ?? >>> print len(u"?") 2 >>> print u"?".upper() ?? >>> str(u"?") '\xc3\x83\xc2\xa1' >>> I'd say idle is broken, as it is not able to respect utf-8 for print (or even len) of unicode strings. OTOH, with some tricks I can manage to get an accented a in a unicode in idle: >>> import unicodedata >>> print unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE") ? >>> print len(unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE")) 1 ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 17:08 Message: Logged In: YES user_id=849994 Using Unicode strings, the OP's example works. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-17 17:04 Message: Logged In: YES user_id=38388 String upper and lower conversion are locale dependent and implemented by the underlying libc, whereas Unicode upper/lower conversion is not and only depends on the Unicode character database. OTOH, there are special cases where the standard Unicode upper/lower mapping is no what you might expect, since the database only provides a single mapping and is not context aware. There's nothing we can do if the libc is broken in some respect. As for the extended case mapping support in Unicode: patches are welcome. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 17:03 Message: Logged In: YES user_id=849994 sgala: it looks like your console sends UTF-8 encoded text. >>> print "?" ? print is just printing out a byte string consisting of two bytes, which your console displays as accent-a. >>> print len("?") 2 A UTF-8-encoded string containing an accented a has two bytes. >>> print "?".upper() ? str.upper() doesn't take locale into account, so the accented a has no uppercase version defined. >>> str("?") '\xc3\xa1' str() applied to a byte string returns that byte string. Since return values from functions are printed by the interactive interpreter using repr() first, you get this representation (which you could also get from "print repr('a')".) >>> print u"?" ? That's also okay. Python knows the terminal encoding and properly translates the byte string to a unicode string of one character. On printout, it converts it to a UTF-8 string again, which your terminal displays correctly. >>> print len(u"?") 1 Since your two-byte-UTF-8 sequence is converted to a unicode character, the length of this unicode string is 1. >>> print u"?".upper() ? There are comprehensive capitalization tables available for unicode. >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) Applying str() to a unicode string must convert it to a byte string. If you don't specify an encoding, the default encoding is "ascii", which can't encode the accented a. Use "a".encode("utf-8"). ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 16:59 Message: Logged In: YES user_id=178886 (I tested it in 2.5rc1), 2.4 gives >>> str(u"?") '\xc3\xa1' instead of the exception ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 16:53 Message: Logged In: YES user_id=178886 The behaviour of python in this area is confusing. See a session with my Spanish keyboard: >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ? >>> print len(u"?") 1 >>> print u"?".upper() ? >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) I guess this is what is happening to the reporter. This violates the least surprising behavior principle in so many different ways that it hurts. Can anybody make sense of it? ---------------------------------------------------------------------- Comment By: Ahmet Bi?kinler (ahmetbiskinler) Date: 2006-08-11 10:10 Message: Logged In: YES user_id=1481281 What happened? Is it solved? How is it going? What is the final step? ...? ...? Could you please give me some information about the bug please? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 From noreply at sourceforge.net Thu Aug 17 21:08:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 12:08:42 -0700 Subject: [ python-Bugs-1528802 ] Turkish Character Message-ID: Bugs item #1528802, was opened at 2006-07-26 07:05 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 Please note that this 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: 6 Submitted By: Ahmet Bi?kinler (ahmetbiskinler) Assigned to: M.-A. Lemburg (lemburg) Summary: Turkish Character Initial Comment: >>> print "May?s".upper() >>> MAY?S >>> import locale >>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254') >>> print "May?s".upper() >>> MAY?S >>> print "???i???".upper() >>> ???I??? MAY?S should be MAYIS ???I??? should be ??????I but >>> "May?s".upper() >>> "MAYIS" is right ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 19:08 Message: Logged In: YES user_id=849994 Please submit that as a separate IDLE bug. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 18:58 Message: Logged In: YES user_id=178886 Idle from 2.5rc1 (svn today) produces a different result than console (with my default, utf-8, encoding): IDLE 1.2c1 >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ?? >>> print len(u"?") 2 >>> print u"?".upper() ?? >>> str(u"?") Traceback (most recent call last): File "", line 1, in str(u"?") UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128) Again, IDLE 1.1.3 (python 2.4.3) produces a different result: IDLE 1.1.3 >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ?? >>> print len(u"?") 2 >>> print u"?".upper() ?? >>> str(u"?") '\xc3\x83\xc2\xa1' >>> I'd say idle is broken, as it is not able to respect utf-8 for print (or even len) of unicode strings. OTOH, with some tricks I can manage to get an accented a in a unicode in idle: >>> import unicodedata >>> print unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE") ? >>> print len(unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE")) 1 ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 15:08 Message: Logged In: YES user_id=849994 Using Unicode strings, the OP's example works. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-17 15:04 Message: Logged In: YES user_id=38388 String upper and lower conversion are locale dependent and implemented by the underlying libc, whereas Unicode upper/lower conversion is not and only depends on the Unicode character database. OTOH, there are special cases where the standard Unicode upper/lower mapping is no what you might expect, since the database only provides a single mapping and is not context aware. There's nothing we can do if the libc is broken in some respect. As for the extended case mapping support in Unicode: patches are welcome. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 15:03 Message: Logged In: YES user_id=849994 sgala: it looks like your console sends UTF-8 encoded text. >>> print "?" ? print is just printing out a byte string consisting of two bytes, which your console displays as accent-a. >>> print len("?") 2 A UTF-8-encoded string containing an accented a has two bytes. >>> print "?".upper() ? str.upper() doesn't take locale into account, so the accented a has no uppercase version defined. >>> str("?") '\xc3\xa1' str() applied to a byte string returns that byte string. Since return values from functions are printed by the interactive interpreter using repr() first, you get this representation (which you could also get from "print repr('a')".) >>> print u"?" ? That's also okay. Python knows the terminal encoding and properly translates the byte string to a unicode string of one character. On printout, it converts it to a UTF-8 string again, which your terminal displays correctly. >>> print len(u"?") 1 Since your two-byte-UTF-8 sequence is converted to a unicode character, the length of this unicode string is 1. >>> print u"?".upper() ? There are comprehensive capitalization tables available for unicode. >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) Applying str() to a unicode string must convert it to a byte string. If you don't specify an encoding, the default encoding is "ascii", which can't encode the accented a. Use "a".encode("utf-8"). ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 14:59 Message: Logged In: YES user_id=178886 (I tested it in 2.5rc1), 2.4 gives >>> str(u"?") '\xc3\xa1' instead of the exception ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 14:53 Message: Logged In: YES user_id=178886 The behaviour of python in this area is confusing. See a session with my Spanish keyboard: >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ? >>> print len(u"?") 1 >>> print u"?".upper() ? >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) I guess this is what is happening to the reporter. This violates the least surprising behavior principle in so many different ways that it hurts. Can anybody make sense of it? ---------------------------------------------------------------------- Comment By: Ahmet Bi?kinler (ahmetbiskinler) Date: 2006-08-11 08:10 Message: Logged In: YES user_id=1481281 What happened? Is it solved? How is it going? What is the final step? ...? ...? Could you please give me some information about the bug please? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 From noreply at sourceforge.net Thu Aug 17 21:17:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 12:17:59 -0700 Subject: [ python-Bugs-1446043 ] unicode('foo', '.utf99') does not raise LookupError Message-ID: Bugs item #1446043, was opened at 2006-03-09 00:55 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&group_id=5470 Please note that this 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: 8 Submitted By: osvenskan (osvenskan) >Assigned to: Neal Norwitz (nnorwitz) Summary: unicode('foo', '.utf99') does not raise LookupError Initial Comment: A very minor inconsistency -- when I call unicode() with an encoding that Python doesn't know about, it usually returns a lookup error (e.g LookupError: unknown encoding: utf99). But when the encoding begins with a dot (ASCII 0x2e), Python instead gives a ValueError: Empty module name. It is certainly correct in raising an error, but it should raise a lookup error, not a value error. I've recreated this under Python 2.4.1/FreeBSD 6.0 and 2.3/OS X. See attachment for recreation steps. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 19:17 Message: Logged In: YES user_id=849994 I'd say that this should be fixed before 2.5 final. Attached patch (the modname that's used for import may not contain a dot anymore...) ---------------------------------------------------------------------- Comment By: osvenskan (osvenskan) Date: 2006-04-06 14:45 Message: Logged In: YES user_id=1119995 I noticed that the documentation for unicode() says, "if the encoding is not known, LookupError is raised". Regarding the 3rd parameter ("errors") to unicode(), the docs say, "Error handling is done according to errors; this specifies the treatment of characters which are invalid in the input encoding. If errors is 'strict' (the default), a ValueError is raised on errors..." ref: http://docs.python.org/lib/built-in-funcs.html That makes the code's current behavior doubly confusing because a the documentation says that a ValueError is reserved for indicating an undecodable byte sequence, not an unknown encoding name. ---------------------------------------------------------------------- Comment By: osvenskan (osvenskan) Date: 2006-03-09 15:04 Message: Logged In: YES user_id=1119995 There are encoding names that contain dots, such as ANSI_X3.4-1968, ANSI_X3.4-1986 and ISO_646.IRV:1991 (as reported by iconv). There are none in iconv's list that begin with a dot. Please note that the behavior of this function has been discussed before in Python bugs 513666 and 960874. Apologies for not referencing them in my original report. Having stepped through the code, I understand how the ValueError is getting generated. My frustration with this as a programmer is that I want to write specific except clauses for each possible exception that a method can raise, but that's impractical if any exception is fair game on any method. So I'm forced to use a catch-all except clause about which the Python documentation says (wisely, IMHO), "Use this with extreme caution, since it is easy to mask a real programming error in this way!" While it is helpful to document errors that a method is *likely* to raise, my code needs to handle all possibilities, not just likely ones. Perhaps the answer is just, "This is how Python works" and if I feel it is a weakness in the language I need to take it up on a different level. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-09 08:16 Message: Logged In: YES user_id=849994 Is it possible for an encoding name to contain dots at all? If not, this would do too: if '.' in modname: continue ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-03-09 08:12 Message: Logged In: YES user_id=89016 The problem is that after normalizing the encoding name a module with this name is imported. Maybe encodings/__init__.py:search_function should do: if ".".join(filter(None, modname.split("."))) != modname: return None ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446043&group_id=5470 From noreply at sourceforge.net Fri Aug 18 00:52:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 15:52:51 -0700 Subject: [ python-Feature Requests-1541463 ] Optimizations for cgi.FieldStorage methods Message-ID: Feature Requests item #1541463, was opened at 2006-08-16 13:37 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1541463&group_id=5470 Please note that this 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: Bob Kline (bkline) Assigned to: Georg Brandl (gbrandl) Summary: Optimizations for cgi.FieldStorage methods Initial Comment: Please add the following optimizations to the FieldStorage class in cgi.py: # ================================================= def keys(self): """Dictionary style keys() method.""" if self.list is None: raise TypeError, "not indexable" return {}.fromkeys([item.name for item in self.list]).keys() def __nonzero__(self): """Support for efficient test of instance""" return self.list and True or False # ================================================= The __nonzero__ method is new, and keys() method is a replacement for code which built the list of unique fields names by hand, and which took several orders of magnitude longer to perform. If you need me to post this as a patch against a certain version, let me know. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-17 18:52 Message: Logged In: YES user_id=764593 Why are you creating a dictionary just to take its keys? Is there a reason the keys method can't just return [item.name for item in self.list] directly? ---------------------------------------------------------------------- Comment By: Bob Kline (bkline) Date: 2006-08-16 13:52 Message: Logged In: YES user_id=291529 I didn't realize this interface would strip leading blanks from lines. Patch submitted to get around this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1541463&group_id=5470 From noreply at sourceforge.net Fri Aug 18 00:56:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 15:56:51 -0700 Subject: [ python-Bugs-1542308 ] Nested finally in generators don't follow PEP 342 Message-ID: Bugs item #1542308, was opened at 2006-08-17 18:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Nested finally in generators don't follow PEP 342 Initial Comment: The close() and GC interaction of generators that use yield inside of finally blocks doesn't execute correctly when nested. See the attached example. More information about the issue is in the Mozilla bug tracker (they found a similar bug in their implementation for JS 1.7): https://bugzilla.mozilla.org/show_bug.cgi?id=349012 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&group_id=5470 From noreply at sourceforge.net Fri Aug 18 01:55:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 16:55:22 -0700 Subject: [ python-Feature Requests-1541463 ] Optimizations for cgi.FieldStorage methods Message-ID: Feature Requests item #1541463, was opened at 2006-08-16 13:37 Message generated for change (Comment added) made by bkline You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1541463&group_id=5470 Please note that this 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: Bob Kline (bkline) Assigned to: Georg Brandl (gbrandl) Summary: Optimizations for cgi.FieldStorage methods Initial Comment: Please add the following optimizations to the FieldStorage class in cgi.py: # ================================================= def keys(self): """Dictionary style keys() method.""" if self.list is None: raise TypeError, "not indexable" return {}.fromkeys([item.name for item in self.list]).keys() def __nonzero__(self): """Support for efficient test of instance""" return self.list and True or False # ================================================= The __nonzero__ method is new, and keys() method is a replacement for code which built the list of unique fields names by hand, and which took several orders of magnitude longer to perform. If you need me to post this as a patch against a certain version, let me know. ---------------------------------------------------------------------- >Comment By: Bob Kline (bkline) Date: 2006-08-17 19:55 Message: Logged In: YES user_id=291529 > Why are you creating a dictionary just to take its keys? Because in order to preserve the original behavior (and to match the documentation), the list returned must contain only one member for each unique field name. The built-in set() would work just as well, though my benchmarks don't show much difference in performance. Something like: return list(set([i.name for i in self.list])) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-17 18:52 Message: Logged In: YES user_id=764593 Why are you creating a dictionary just to take its keys? Is there a reason the keys method can't just return [item.name for item in self.list] directly? ---------------------------------------------------------------------- Comment By: Bob Kline (bkline) Date: 2006-08-16 13:52 Message: Logged In: YES user_id=291529 I didn't realize this interface would strip leading blanks from lines. Patch submitted to get around this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1541463&group_id=5470 From noreply at sourceforge.net Fri Aug 18 06:33:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 21:33:29 -0700 Subject: [ python-Bugs-1542407 ] httplib reads one byte per system call Message-ID: Bugs item #1542407, was opened at 2006-08-18 00: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=1542407&group_id=5470 Please note that this 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: Zoyd Wheeler (zoyd2k) Assigned to: Nobody/Anonymous (nobody) Summary: httplib reads one byte per system call Initial Comment: The HTTPResponse class in httplib.py contains the following line in its __init__ method: self.fp = sock.makefile('rb', 0) The zero in that second (bufsize) argument overrides the default behavior of the socket filedescriptor in its readline() method, which is to read in a buffer's worth of data from the socket at a time and only hit the socket again if the buffer runs dry. When bufsize is set to zero, the filedescriptor sets its internal buffer size to one. As a result, readline() makes a system call for every byte of data consumed. Since httplib uses readline to obtain the http header, that's an awful lot of system calls. We noticed this when trying to build a fairly aggressive application on top of xmlrpclib (which relies on httplib); we saw tons of system call activity. There is no comment near this line of code to indicate whether this behavior is intended or not. If it is not intended, the patch is to simply remove the second argument and rely on the default (or allow the caller to specify a buffer size). In case reading a byte at a time is actually intended, we have a simple work-around for those who care to use it. In the python code that uses httplib, add the following: import httplib ... class HTTPResponse(httplib.HTTPResponse): def __init__(self, sock, **kw): httplib.HTTPResponse.__init__(self, sock, **kw) self.fp = sock.makefile('rb') httplib.HTTPConnection.response_class = HTTPResponse ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542407&group_id=5470 From noreply at sourceforge.net Fri Aug 18 06:55:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 21:55:14 -0700 Subject: [ python-Bugs-1541697 ] Recently introduced sgmllib regexp bug hangs Python Message-ID: Bugs item #1541697, was opened at 2006-08-17 10:51 Message generated for change (Comment added) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&group_id=5470 Please note that this 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: 8 Submitted By: John J Lee (jjlee) Assigned to: Nobody/Anonymous (nobody) Summary: Recently introduced sgmllib regexp bug hangs Python Initial Comment: Looks like revision 47154 introduced a regexp that hangs Python (Ctrl-C won't kill the process, CPU usage sits near 100%) under some circumstances. A test case is attached (sgmllib.html and hang_sgmllib.py). The problem isn't seen if you read the whole file (or nearly the whole file) at once. But that doesn't make it a non-bug, AFAICS. I'm not sure what the problem is, but presumably the relevant part of the patch is this: +starttag = re.compile(r'<[a-zA-Z][-_.:a-zA-Z0-9]*\s*(' + r'\s*([a-zA-Z_][-:.a-zA-Z_0-9]*)(\s*=\s*' + r'(\'[^\']*\'|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~@]' + r'[][\-a-zA-Z0-9./,:;+*%?!&$\(\)_#=~\'"@]*(?=[\s>/<])))?' + r')*\s*/?\s*(?=[<>])') The patch attached to bug 1515142 (also from Sam Ruby -- claims to fix a regression introduced by his recent sgmllib patches, and has not yet been applied) does NOT fix the problem. ---------------------------------------------------------------------- >Comment By: George Yoshida (quiver) Date: 2006-08-18 13:55 Message: Logged In: YES user_id=671362 Slimmed down test case is attached.(The regex pattern in question is used) FYI, r47154 is backported to 2.4 branch(r47155). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541697&group_id=5470 From noreply at sourceforge.net Fri Aug 18 08:11:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 23:11:41 -0700 Subject: [ python-Bugs-1542432 ] python-2.5c1.msi contains ICE validation errors and warnings Message-ID: Bugs item #1542432, was opened at 2006-08-18 06: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=1542432&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Arnson (barnson) Assigned to: Nobody/Anonymous (nobody) Summary: python-2.5c1.msi contains ICE validation errors and warnings Initial Comment: python-2.5c1.msi contains the following ICE validation errors and warnings: ICE21 ERROR Component: 'REGISTRY.tcl' does not belong to any Feature. === REGISTRY.tcl is still getting installed but it should be listed in FeatureComponents. ICE57 WARNING Component 'REGISTRY.def' has a registry entry that can be either per-user or per-machine and a per-machine KeyPath. ICE57 ERROR Component 'REGISTRY.doc' has both per-user data and a keypath that can be either per-user or per-machine. ICE57 ERROR Component 'REGISTRY' has both per-user data and a keypath that can be either per-user or per-machine. === I think you can fix all these by using an appropriate registry entry as the KeyPath. ICE67 WARNING The shortcut 'Manual' is a non-advertised shortcut with a file target. The shortcut and target are installed by different components, and the target component can run locally or from source. ICE69 WARNING Mismatched component reference. Entry 'Manual' of the Shortcut table belongs to component 'REGISTRY.doc'. However, the formatted string in column 'Target' references file 'Python25.chm' which belongs to component 'documentation'. Components are in the same feature. === These are fairly benign, but you can clean them up if you want by moving the shortcut into the "documentation" component. (The idea is that related resources [files, registry values, shortcuts] live in the same component, so when one is installed, all are installed atomically.) You can run validation from Orca or the MsiVal2, both of which are in the Platform/Windows SDK. Details about ICEs are available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/ice_reference.asp. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542432&group_id=5470 From noreply at sourceforge.net Fri Aug 18 08:53:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Aug 2006 23:53:58 -0700 Subject: [ python-Bugs-1542432 ] python-2.5c1.msi contains ICE validation errors and warnings Message-ID: Bugs item #1542432, was opened at 2006-08-18 08:11 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542432&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Arnson (barnson) Assigned to: Nobody/Anonymous (nobody) Summary: python-2.5c1.msi contains ICE validation errors and warnings Initial Comment: python-2.5c1.msi contains the following ICE validation errors and warnings: ICE21 ERROR Component: 'REGISTRY.tcl' does not belong to any Feature. === REGISTRY.tcl is still getting installed but it should be listed in FeatureComponents. ICE57 WARNING Component 'REGISTRY.def' has a registry entry that can be either per-user or per-machine and a per-machine KeyPath. ICE57 ERROR Component 'REGISTRY.doc' has both per-user data and a keypath that can be either per-user or per-machine. ICE57 ERROR Component 'REGISTRY' has both per-user data and a keypath that can be either per-user or per-machine. === I think you can fix all these by using an appropriate registry entry as the KeyPath. ICE67 WARNING The shortcut 'Manual' is a non-advertised shortcut with a file target. The shortcut and target are installed by different components, and the target component can run locally or from source. ICE69 WARNING Mismatched component reference. Entry 'Manual' of the Shortcut table belongs to component 'REGISTRY.doc'. However, the formatted string in column 'Target' references file 'Python25.chm' which belongs to component 'documentation'. Components are in the same feature. === These are fairly benign, but you can clean them up if you want by moving the shortcut into the "documentation" component. (The idea is that related resources [files, registry values, shortcuts] live in the same component, so when one is installed, all are installed atomically.) You can run validation from Orca or the MsiVal2, both of which are in the Platform/Windows SDK. Details about ICEs are available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/ice_reference.asp. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-18 08:53 Message: Logged In: YES user_id=21627 These validation errors existed ever since Python 2.4. Is there an actual problem? I could not find a way to fix them, and believe some of the ICEs are broken. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542432&group_id=5470 From noreply at sourceforge.net Fri Aug 18 09:04:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 00:04:32 -0700 Subject: [ python-Bugs-1541420 ] tools and demo missing from windows Message-ID: Bugs item #1541420, was opened at 2006-08-16 18:19 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541420&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None >Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: tools and demo missing from windows Initial Comment: The windows distribution (I'm currently looking at 2.5b3) does not contain a Demo directory, and the Tools directory contains only five subdirectories (i18n, pynche, Scripts, versioncheck, webchecker) SVN Head lists 20 directories under Demo and 17 under Tools. At a first pass, all except tools/audiopy (Solaris specific) are relevant on Windows, and some tools (such as freeze, msi) even have windows-specific code. I've marked it 2.5 because consistency with other platforms seems like a bugfix, even if it does introduce new features to windows. (And note that it only adds new files that are not on the standard path, which should limit the risks.) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-18 09:04 Message: Logged In: YES user_id=21627 This must wait until 2.5.1; more likely 2.6. The Windows distribution was structured that way always, so it's not a regression. "Consistency with other platforms" is not a valid argument: there are no binary distributions for other platforms except for OSX (whether that includes Tools or Demo, I don't know). The source distribution for Windows is the very same as the source distribution for other platforms, and it does include Tools and Demo, so it's (trivially) consistent. I don't think the Demo directory should be included. The equivalent of a binary distribution on Unix (make install) doesn't install the Demos, either. As for the Tools directory: this traditionally includes directories on a per-request basis. If there is an actual need for another tool, it should be added. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541420&group_id=5470 From noreply at sourceforge.net Fri Aug 18 09:18:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 00:18:11 -0700 Subject: [ python-Bugs-1541671 ] bsddb can't use unicode filenames Message-ID: Bugs item #1541671, was opened at 2006-08-17 02:48 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541671&group_id=5470 Please note that this 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: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: bsddb can't use unicode filenames Initial Comment: with Python 2.5b3, Here is an attempt to use a unicode filename with bsddb: >>> dbe = db.DBEnv() >>> dbe.open(u'\u03b3\u03bb\u03ce\u03c3\u03c32', db.DB_CREATE | db.DB_INIT_MPOOL) Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-4: ordinal not in range(128) This is on Windows XP. Here are some indications that the underlying SleepyCat library ought to be able to do the right thing here: http://www.sleepycat.com/xmldocs/ref/build_win/unicode.html http://www.sleepycat.com/update/4.3.29/if.4.3.29.html ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-18 09:18 Message: Logged In: YES user_id=21627 The sleepycat Unicode build procedure is not usable for Python. The exposed API (db_open) etc. still operates on char* strings. It then internally decodes them to WCHAR_T before passing them to the Win32 API. Why they do this is beyond me; I can't see any advantage in doing so (for the users of the library, nothing changes). It would be possible to change _bsddb to encode Unicode strings automatically with the "mbcs" codec. Not sure whether that would help in your case, as I don't know what the system ANSI code page on your installation is. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541671&group_id=5470 From noreply at sourceforge.net Fri Aug 18 09:29:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 00:29:04 -0700 Subject: [ python-Bugs-1541682 ] Incorrect example calls to PyObject_SetItem Message-ID: Bugs item #1541682, was opened at 2006-08-17 01:13 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541682&group_id=5470 Please note that this 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 Machin (sjmachin) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect example calls to PyObject_SetItem Initial Comment: http://docs.python.org/dev/api/refcountDetails.html Example acts as though the 2nd arg to PyObject_SetItem is a C int (as it is for the List and Sequence varieties) -- it is in fact a (PyObject *) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-18 07:29 Message: Logged In: YES user_id=849994 This is now fixed in rev. 51363--51365. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1541682&group_id=5470 From noreply at sourceforge.net Fri Aug 18 10:50:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 01:50:14 -0700 Subject: [ python-Bugs-1542308 ] Nested finally in generators don't follow PEP 342 Message-ID: Bugs item #1542308, was opened at 2006-08-17 22:56 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None >Priority: 8 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Nested finally in generators don't follow PEP 342 Initial Comment: The close() and GC interaction of generators that use yield inside of finally blocks doesn't execute correctly when nested. See the attached example. More information about the issue is in the Mozilla bug tracker (they found a similar bug in their implementation for JS 1.7): https://bugzilla.mozilla.org/show_bug.cgi?id=349012 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&group_id=5470 From noreply at sourceforge.net Fri Aug 18 11:49:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 02:49:25 -0700 Subject: [ python-Bugs-1533105 ] NetBSD build with --with-pydebug causes SIGSEGV Message-ID: Bugs item #1533105, was opened at 2006-08-02 22:00 Message generated for change (Comment added) made by ocean-city You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533105&group_id=5470 Please note that this 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: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: NetBSD build with --with-pydebug causes SIGSEGV Initial Comment: The testInfiniteRecursion test in Lib/test/test_exceptions.py causes Python to segfault if it has been compiled on NetBSD with --with-pydebug. This is due to the fact that the default stack size on NetBSD is 2MB and Python tries to allocate memory for debugging information on the stack. The documentation (README under 'Setting the optimization/debugging options'?) should be updated to state that if you want to run the test suite with debugging enabled in the interpreter, you are advised to increase the stack size, probably to 4096. This issue is also in release24-maint. Matt ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-08-18 18:49 Message: Logged In: YES user_id=1200846 Sorry for interruption. I encountered this problem on VC6 debug build too. Is there any chance to supress recursion limit for this test like this? Index: Lib/test/test_exceptions.py =================================================================== --- Lib/test/test_exceptions.py (revision 51370) +++ Lib/test/test_exceptions.py (working copy) @@ -306,16 +306,25 @@ self.assertEquals(x.fancy_arg, 42) def testInfiniteRecursion(self): + def run(f): + import sys + limit = sys.getrecursionlimit() + sys.setrecursionlimit(400) # supress for debug mode + try: + self.assertRaises(RuntimeError, f) + finally: + sys.setrecursionlimit(limit) + def f(): return f() - self.assertRaises(RuntimeError, f) + run(f) def g(): try: return g() except ValueError: return -1 - self.assertRaises(RuntimeError, g) + run(g) def test_main(): run_unittest(ExceptionTests) ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-08-09 19:23 Message: Logged In: YES user_id=1126061 Patches for trunk and 2.4 attached. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-09 14:40 Message: Logged In: YES user_id=33168 Matt, can you make a patch? Doc changes are fine to go into 2.5 (and 2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533105&group_id=5470 From noreply at sourceforge.net Fri Aug 18 11:55:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 02:55:24 -0700 Subject: [ python-Bugs-1533105 ] NetBSD build with --with-pydebug causes SIGSEGV Message-ID: Bugs item #1533105, was opened at 2006-08-02 13:00 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533105&group_id=5470 Please note that this 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: Matt Fleming (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: NetBSD build with --with-pydebug causes SIGSEGV Initial Comment: The testInfiniteRecursion test in Lib/test/test_exceptions.py causes Python to segfault if it has been compiled on NetBSD with --with-pydebug. This is due to the fact that the default stack size on NetBSD is 2MB and Python tries to allocate memory for debugging information on the stack. The documentation (README under 'Setting the optimization/debugging options'?) should be updated to state that if you want to run the test suite with debugging enabled in the interpreter, you are advised to increase the stack size, probably to 4096. This issue is also in release24-maint. Matt ---------------------------------------------------------------------- >Comment By: Matt Fleming (splitscreen) Date: 2006-08-18 09:55 Message: Logged In: YES user_id=1126061 Hmm.. perhaps this problem is more widespread that I'd realised. Apparently the default stack size on windows is 1MB (someone correct me if I'm wrong). Perhaps there should be an option with the configure script to change the stack size? Alternatively we could stop allocating space for debug error messages on the stack ;-) ---------------------------------------------------------------------- Comment By: Hirokazu Yamamoto (ocean-city) Date: 2006-08-18 09:49 Message: Logged In: YES user_id=1200846 Sorry for interruption. I encountered this problem on VC6 debug build too. Is there any chance to supress recursion limit for this test like this? Index: Lib/test/test_exceptions.py =================================================================== --- Lib/test/test_exceptions.py (revision 51370) +++ Lib/test/test_exceptions.py (working copy) @@ -306,16 +306,25 @@ self.assertEquals(x.fancy_arg, 42) def testInfiniteRecursion(self): + def run(f): + import sys + limit = sys.getrecursionlimit() + sys.setrecursionlimit(400) # supress for debug mode + try: + self.assertRaises(RuntimeError, f) + finally: + sys.setrecursionlimit(limit) + def f(): return f() - self.assertRaises(RuntimeError, f) + run(f) def g(): try: return g() except ValueError: return -1 - self.assertRaises(RuntimeError, g) + run(g) def test_main(): run_unittest(ExceptionTests) ---------------------------------------------------------------------- Comment By: Matt Fleming (splitscreen) Date: 2006-08-09 10:23 Message: Logged In: YES user_id=1126061 Patches for trunk and 2.4 attached. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-09 05:40 Message: Logged In: YES user_id=33168 Matt, can you make a patch? Doc changes are fine to go into 2.5 (and 2.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1533105&group_id=5470 From noreply at sourceforge.net Fri Aug 18 16:37:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 07:37:06 -0700 Subject: [ python-Bugs-1542677 ] IDLE shell doesn't accept non ascii char input Message-ID: Bugs item #1542677, was opened at 2006-08-18 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=1542677&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Submitted By: Santiago Gala (sgala) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE shell doesn't accept non ascii char input Initial Comment: in bug 1528802 ( see https://sourceforge.net/tracker/index.php?func=detail&aid=1528802&group_id=5470&atid=105470 ) , I noticed that idle shell behaviour WRT non-ascii chars was different than python console, and possibly broken. For example, IDLE produces: >>> print u"?" ?? >>> print len(u"?") 2 >>> print "?" ? >>> print len("?") 2 ------- a python shell (gnome-terminal): >>> print u"?" ? >>> print len(u"?") 1 >>> print "?" ? >>> print len("?") 2 Both are using es_ES.utf-8 system encoding. IDLE can manage unicode, it is just input that gives problems: >>> import unicodedata >>> print unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE") ? >>> print len(unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE")) 1 Not that I like that much the violation of the least surprising behaviour that python console offers with non-ascii letters, but at least some internal consistency would be great, until python 3000 gives us true strings. I'm using python 2.5 (svn trunk) --with-unicode=ucs4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542677&group_id=5470 From noreply at sourceforge.net Fri Aug 18 16:37:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 07:37:46 -0700 Subject: [ python-Bugs-1528802 ] Turkish Character Message-ID: Bugs item #1528802, was opened at 2006-07-26 09:05 Message generated for change (Comment added) made by sgala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 Please note that this 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: 6 Submitted By: Ahmet Bi?kinler (ahmetbiskinler) Assigned to: M.-A. Lemburg (lemburg) Summary: Turkish Character Initial Comment: >>> print "May?s".upper() >>> MAY?S >>> import locale >>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254') >>> print "May?s".upper() >>> MAY?S >>> print "???i???".upper() >>> ???I??? MAY?S should be MAYIS ???I??? should be ??????I but >>> "May?s".upper() >>> "MAYIS" is right ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-18 16:37 Message: Logged In: YES user_id=178886 Done: Bug #1542677 ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 21:08 Message: Logged In: YES user_id=849994 Please submit that as a separate IDLE bug. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 20:58 Message: Logged In: YES user_id=178886 Idle from 2.5rc1 (svn today) produces a different result than console (with my default, utf-8, encoding): IDLE 1.2c1 >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ?? >>> print len(u"?") 2 >>> print u"?".upper() ?? >>> str(u"?") Traceback (most recent call last): File "", line 1, in str(u"?") UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128) Again, IDLE 1.1.3 (python 2.4.3) produces a different result: IDLE 1.1.3 >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ?? >>> print len(u"?") 2 >>> print u"?".upper() ?? >>> str(u"?") '\xc3\x83\xc2\xa1' >>> I'd say idle is broken, as it is not able to respect utf-8 for print (or even len) of unicode strings. OTOH, with some tricks I can manage to get an accented a in a unicode in idle: >>> import unicodedata >>> print unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE") ? >>> print len(unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE")) 1 ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 17:08 Message: Logged In: YES user_id=849994 Using Unicode strings, the OP's example works. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-17 17:04 Message: Logged In: YES user_id=38388 String upper and lower conversion are locale dependent and implemented by the underlying libc, whereas Unicode upper/lower conversion is not and only depends on the Unicode character database. OTOH, there are special cases where the standard Unicode upper/lower mapping is no what you might expect, since the database only provides a single mapping and is not context aware. There's nothing we can do if the libc is broken in some respect. As for the extended case mapping support in Unicode: patches are welcome. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 17:03 Message: Logged In: YES user_id=849994 sgala: it looks like your console sends UTF-8 encoded text. >>> print "?" ? print is just printing out a byte string consisting of two bytes, which your console displays as accent-a. >>> print len("?") 2 A UTF-8-encoded string containing an accented a has two bytes. >>> print "?".upper() ? str.upper() doesn't take locale into account, so the accented a has no uppercase version defined. >>> str("?") '\xc3\xa1' str() applied to a byte string returns that byte string. Since return values from functions are printed by the interactive interpreter using repr() first, you get this representation (which you could also get from "print repr('a')".) >>> print u"?" ? That's also okay. Python knows the terminal encoding and properly translates the byte string to a unicode string of one character. On printout, it converts it to a UTF-8 string again, which your terminal displays correctly. >>> print len(u"?") 1 Since your two-byte-UTF-8 sequence is converted to a unicode character, the length of this unicode string is 1. >>> print u"?".upper() ? There are comprehensive capitalization tables available for unicode. >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) Applying str() to a unicode string must convert it to a byte string. If you don't specify an encoding, the default encoding is "ascii", which can't encode the accented a. Use "a".encode("utf-8"). ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 16:59 Message: Logged In: YES user_id=178886 (I tested it in 2.5rc1), 2.4 gives >>> str(u"?") '\xc3\xa1' instead of the exception ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 16:53 Message: Logged In: YES user_id=178886 The behaviour of python in this area is confusing. See a session with my Spanish keyboard: >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ? >>> print len(u"?") 1 >>> print u"?".upper() ? >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) I guess this is what is happening to the reporter. This violates the least surprising behavior principle in so many different ways that it hurts. Can anybody make sense of it? ---------------------------------------------------------------------- Comment By: Ahmet Bi?kinler (ahmetbiskinler) Date: 2006-08-11 10:10 Message: Logged In: YES user_id=1481281 What happened? Is it solved? How is it going? What is the final step? ...? ...? Could you please give me some information about the bug please? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 From noreply at sourceforge.net Fri Aug 18 17:10:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 08:10:15 -0700 Subject: [ python-Bugs-1542693 ] Bug in definition of PyImport_ImportModuleEx macro Message-ID: Bugs item #1542693, was opened at 2006-08-18 11:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542693&group_id=5470 Please note that this 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: Chris Stawarz (cstawarz) Assigned to: Nobody/Anonymous (nobody) Summary: Bug in definition of PyImport_ImportModuleEx macro Initial Comment: In Python 2.5c1 and SVN trunk rev 42649, the file import.h has a bug in the definition of the macro PyImport_ImportModuleEx. From the code: #define PyImport_ImportModuleEx(n, g, l, f) \ PyImport_ImportModuleLevel(n, g, l, f, -1); The trailing semicolon shouldn't be there, as it causes compilation to fail when you do things like if (NULL == (module = PyImport_ImportModuleEx(...))) ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542693&group_id=5470 From noreply at sourceforge.net Fri Aug 18 17:14:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 08:14:09 -0700 Subject: [ python-Bugs-1542693 ] Bug in definition of PyImport_ImportModuleEx macro Message-ID: Bugs item #1542693, was opened at 2006-08-18 15:10 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542693&group_id=5470 Please note that this 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: 8 Submitted By: Chris Stawarz (cstawarz) >Assigned to: Neal Norwitz (nnorwitz) Summary: Bug in definition of PyImport_ImportModuleEx macro Initial Comment: In Python 2.5c1 and SVN trunk rev 42649, the file import.h has a bug in the definition of the macro PyImport_ImportModuleEx. From the code: #define PyImport_ImportModuleEx(n, g, l, f) \ PyImport_ImportModuleLevel(n, g, l, f, -1); The trailing semicolon shouldn't be there, as it causes compilation to fail when you do things like if (NULL == (module = PyImport_ImportModuleEx(...))) ... ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-18 15:14 Message: Logged In: YES user_id=849994 This seems correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542693&group_id=5470 From noreply at sourceforge.net Sat Aug 19 00:01:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 15:01:25 -0700 Subject: [ python-Bugs-1467929 ] %-formatting and dicts Message-ID: Bugs item #1467929, was opened at 2006-04-10 15:39 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Anthony Baxter (anthonybaxter) Summary: %-formatting and dicts Initial Comment: This looks like a bug in the way the %-formatting code works or is it a feature ? >>> '%s %(a)s' % {'a': 'xyz'} "{'a': 'xyz'} xyz" >>> u'%s %(a)s' % {'a': 'xyz'} u"{'a': 'xyz'} xyz" Note that both strings and Unicode are affected. Python 2.3 and 2.4 also show this behavior. I would have expected an exception or the %-formatter simply ignoring the first %s. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-18 18:01 Message: Logged In: YES user_id=764593 Just a bit of encouragement for checking consistency like this; the explicit error message would have helped with a mistake I made earlier today. For one of several keys, I mistyped it as "(%key)s", and a message about "not enough values" just didn't make sense. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-04 09:26 Message: Logged In: YES user_id=38388 The patch looks OK. I'd make it a TypeError and use "cannot use positional and named formatting parameters at the same time" as message. Thanks. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-04 09:21 Message: Logged In: YES user_id=44345 Looks okay to me, though why is the FORMAT_TYPE_UNKNOWN test necessary in the second case but not the first? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-07-25 08:35 Message: Logged In: YES user_id=11375 So, what should '%s' % {} do? Should it be 1) '{}' or 2) an error because the argument is a mapping but the format specifier doesn't have a '(key)'? I've attached a draft patch that fixes stringobject.c; if the approach is deemed OK, I'll apply it to unicodeobject.c, too. PyString_Format() records the type of argument being processed (a tuple or a mapping) and raises ValueError if you mix them, at the cost of two extra comparisons for each format specifier processed. This preserves the current behaviour of '%s' % dictionary. Questions: 1) is the approach reasonably clear? 2) are the additional two comparisons unacceptably slow? 3) Is ValueError the right exception? 4) can someone come up with a better exception message than "both keyed and unkeyed format specifiers used"? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-07-24 16:07 Message: Logged In: YES user_id=21627 IMO, it's correct to break backwards compatibility, as the current behaviour clearly violates the spec; I'm not sure whether it's good to break the behaviour *now* (i.e. with no further betas before the release of 2.5). Deferring to the release manager. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 09:37 Message: Logged In: YES user_id=849994 The library ref specifies that if a dict is supplied, the format specifiers MUST include a mapping key, so the right thing to do would be to raise an exception. Is it worth breaking backwards compatibility, Martin? ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2006-04-14 04:33 Message: Logged In: YES user_id=1185570 It looks as though it's a feature... The first %s will print the whole dictionary as a string, the second, only that value looked up by the key. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470 From noreply at sourceforge.net Sat Aug 19 00:17:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 15:17:35 -0700 Subject: [ python-Bugs-1467929 ] %-formatting and dicts Message-ID: Bugs item #1467929, was opened at 2006-04-10 21:39 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Anthony Baxter (anthonybaxter) Summary: %-formatting and dicts Initial Comment: This looks like a bug in the way the %-formatting code works or is it a feature ? >>> '%s %(a)s' % {'a': 'xyz'} "{'a': 'xyz'} xyz" >>> u'%s %(a)s' % {'a': 'xyz'} u"{'a': 'xyz'} xyz" Note that both strings and Unicode are affected. Python 2.3 and 2.4 also show this behavior. I would have expected an exception or the %-formatter simply ignoring the first %s. ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-19 00:17 Message: Logged In: YES user_id=38388 Should this patch be applied to the 2.5 branch ? And if so, before or after the release of 2.5 ? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-19 00:01 Message: Logged In: YES user_id=764593 Just a bit of encouragement for checking consistency like this; the explicit error message would have helped with a mistake I made earlier today. For one of several keys, I mistyped it as "(%key)s", and a message about "not enough values" just didn't make sense. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-04 15:26 Message: Logged In: YES user_id=38388 The patch looks OK. I'd make it a TypeError and use "cannot use positional and named formatting parameters at the same time" as message. Thanks. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-04 15:21 Message: Logged In: YES user_id=44345 Looks okay to me, though why is the FORMAT_TYPE_UNKNOWN test necessary in the second case but not the first? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-07-25 14:35 Message: Logged In: YES user_id=11375 So, what should '%s' % {} do? Should it be 1) '{}' or 2) an error because the argument is a mapping but the format specifier doesn't have a '(key)'? I've attached a draft patch that fixes stringobject.c; if the approach is deemed OK, I'll apply it to unicodeobject.c, too. PyString_Format() records the type of argument being processed (a tuple or a mapping) and raises ValueError if you mix them, at the cost of two extra comparisons for each format specifier processed. This preserves the current behaviour of '%s' % dictionary. Questions: 1) is the approach reasonably clear? 2) are the additional two comparisons unacceptably slow? 3) Is ValueError the right exception? 4) can someone come up with a better exception message than "both keyed and unkeyed format specifiers used"? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-07-24 22:07 Message: Logged In: YES user_id=21627 IMO, it's correct to break backwards compatibility, as the current behaviour clearly violates the spec; I'm not sure whether it's good to break the behaviour *now* (i.e. with no further betas before the release of 2.5). Deferring to the release manager. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 15:37 Message: Logged In: YES user_id=849994 The library ref specifies that if a dict is supplied, the format specifiers MUST include a mapping key, so the right thing to do would be to raise an exception. Is it worth breaking backwards compatibility, Martin? ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2006-04-14 10:33 Message: Logged In: YES user_id=1185570 It looks as though it's a feature... The first %s will print the whole dictionary as a string, the second, only that value looked up by the key. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470 From noreply at sourceforge.net Sat Aug 19 01:17:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 16:17:07 -0700 Subject: [ python-Feature Requests-1542920 ] wsgi.org link in wsgiref Message-ID: Feature Requests item #1542920, was opened at 2006-08-18 18:17 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=1542920&group_id=5470 Please note that this 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: Ian Bicking (ianbicking) Assigned to: Nobody/Anonymous (nobody) Summary: wsgi.org link in wsgiref Initial Comment: Please add a link to http://wsgi.org to the wsgiref module page -- this site links to various resources to learn and use WSGI, which is probably apropos to someone reading about that module. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1542920&group_id=5470 From noreply at sourceforge.net Sat Aug 19 03:51:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 18:51:33 -0700 Subject: [ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9 Message-ID: Bugs item #1542949, was opened at 2006-08-18 21: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=1542949&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Submitted By: David Strozzi (dstrozzi) Assigned to: Nobody/Anonymous (nobody) Summary: idle in python 2.5c1 freezes on macos 10.3.9 Initial Comment: Hi, I installed python 2.5b3 on a powerbook ppc laptop running macos 10.3.9 a few days ago. python and idle worked. Now I installed 2.5c1. python works fine from a terminal. When I start idle, it loads, puts up its menu bar, opens a shell window, displays usual startup info, and gives me a prompt. But, I can't type or get a cursor. Whenever I move the mouse over the idle window or menu bar, I get a spinning color wheel and can't do anything. I deleted the whole /library/python tree, reinstalled 2.5c1, and exactly the same thing happened. Oh, and I rebooted :) Not sure what is happening, or how to diagnose. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 From noreply at sourceforge.net Sat Aug 19 03:54:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 18:54:04 -0700 Subject: [ python-Bugs-1459963 ] urllib2 changes header names Message-ID: Bugs item #1459963, was opened at 2006-03-28 13:02 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&group_id=5470 Please note that this 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: Michael Vert (vimico) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 changes header names Initial Comment: It seems that urllib2 changes the writing of any additional supplied headers, i.e. "User-Agent" becomes "User-agent", "TEST-HEADER" becomes "Test-header". A few sites do not recognize "User-agent" and insist on "User-Agent". Fix: remove all occurences of capitalize() in urllib2. ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-08-19 02:54 Message: Logged In: YES user_id=261020 Patch 1459963 (applied in 50842) should be reverted and a better patch applied (see below), since this one needlessly breaks the old (albeit undocumented) interface of direct access to request.headers (which existed prior to the introduction of the .get_header() &c. methods). Patch 1542948 reverts 50842's changes to urllib2 (it does not revert the changes to urllib) and fixes the reported issue with a one-line fix in AbstractHTTPHandler (.title()-case the HTTP headers before sending them to httplib). That fix is also more localised to HTTP -- urllib2 knows about other protocols too. This patch also corrects a mis-wording in Misc/NEWS: the old case convention was not strictly incorrect (according to RFC 2616), but just did not follow the usual title-case convention. If the original patch was applied to the 2.4 maintenance branch, I guess patch 1542948 should be applied there too. (Just BTW: With hindsight, the methods should never have been introduced (which was done when the "unredirected" headers were introduced), but rather request.headers changed to be a class != dict: that was my fault, and it's too late to fix that...) ---------------------------------------------------------------------- Comment By: Michael Vert (vimico) Date: 2006-03-28 16:32 Message: Logged In: YES user_id=928834 I checked the database before submitting... I admit, I haven't gone back 2 years. :-) It seems to be the same bug. But it was still present in 2.4.2 (version used in Ubuntu Breezy). ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-03-28 13:40 Message: Logged In: YES user_id=849994 Some normalizing is important to prevent duplicate headers. Changed capitalize() to title() to match the default casing (now user-agent becomes User-Agent) in rev. 43399. ---------------------------------------------------------------------- Comment By: Jens Diemer (pylucid) Date: 2006-03-28 13:16 Message: Logged In: YES user_id=1330780 There are old, closed Bug-Reports: https://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=994101 ?!?!? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459963&group_id=5470 From noreply at sourceforge.net Sat Aug 19 05:09:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 20:09:54 -0700 Subject: [ python-Bugs-971213 ] another threads+readline+signals nasty Message-ID: Bugs item #971213, was opened at 2004-06-11 08:30 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971213&group_id=5470 Please note that this 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: Works For Me Priority: 7 Submitted By: Anthony Baxter (anthonybaxter) >Assigned to: Anthony Baxter (anthonybaxter) Summary: another threads+readline+signals nasty Initial Comment: python -c "import time, readline, thread; thread.start_new_thread(raw_input, ()); time.sleep(2)" Segfaults on ^C Fails on Linux, freebsd. On linux (FC - using kernel 2.6.1, glibc 2.3.3, gcc-3.3.3) (gdb) where #0 0x002627a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x008172b1 in ___newselect_nocancel () from /lib/tls/libc.so.6 #2 0x0011280b in time_sleep (self=0x0, args=0xb7fe17ac) at Modules/timemodule.c:815 on FreeBSD 5.2.1-RC, a different error. Fatal error 'longjmp()ing between thread contexts is undefined by POSIX 1003.1' at line 72 in file /usr/src/lib/libc_r/uthread/uthread_jmp.c (errno = 2) Abort (core dumped) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-18 20:09 Message: Logged In: YES user_id=33168 This doesn't crash for me any more. I remember there was another fix for socket timeouts and Ctrl-C. Maybe that fixed this too? Anthony, can you reproduce this? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-10-03 04:13 Message: Logged In: YES user_id=6656 I can't, on OS X or debian. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-02 21:12 Message: Logged In: YES user_id=33168 I can reproduce with cvs head (gentoo linux/amd64). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-07 02:03 Message: Logged In: YES user_id=6656 I think this is fixed now, as in I can't reproduce it with CVS HEAD. Not sure why! I can think of a few fixes that might be responsible. It still messes the terminal up, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 14:41 Message: Logged In: YES user_id=6656 Bah, this still segfaults with CVS head. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-21 03:45 Message: Logged In: YES user_id=6656 Can you try the patch that's *now* in 960406? It seems to help for me (but I really would rather not think too hard about this!). ---------------------------------------------------------------------- Comment By: Michal Pasternak (mpasternak) Date: 2004-06-11 08:43 Message: Logged In: YES user_id=799039 readline used on FreeBSD was readline-4.3pl5; everything else: gcc 3.3.3, ncurses, libc were standard from 5.2.1. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 08:39 Message: Logged In: YES user_id=29957 The patch in #960406 doesn't help here. The FC test system also has readline-4.3, if it helps, as does the FreeBSD box. It apparently doesn't crash on OSX. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 08:38 Message: Logged In: YES user_id=6656 Hmm. Doesn't crash on OS X. Messes the terminal up good and proper, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971213&group_id=5470 From noreply at sourceforge.net Sat Aug 19 06:25:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 21:25:48 -0700 Subject: [ python-Bugs-1542693 ] Bug in definition of PyImport_ImportModuleEx macro Message-ID: Bugs item #1542693, was opened at 2006-08-18 08:10 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542693&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Chris Stawarz (cstawarz) Assigned to: Neal Norwitz (nnorwitz) Summary: Bug in definition of PyImport_ImportModuleEx macro Initial Comment: In Python 2.5c1 and SVN trunk rev 42649, the file import.h has a bug in the definition of the macro PyImport_ImportModuleEx. From the code: #define PyImport_ImportModuleEx(n, g, l, f) \ PyImport_ImportModuleLevel(n, g, l, f, -1); The trailing semicolon shouldn't be there, as it causes compilation to fail when you do things like if (NULL == (module = PyImport_ImportModuleEx(...))) ... ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-18 21:25 Message: Logged In: YES user_id=33168 Thanks! Committed revision 51399. (2.5) Committed revision 51402. (2.6) ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-18 08:14 Message: Logged In: YES user_id=849994 This seems correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542693&group_id=5470 From noreply at sourceforge.net Sat Aug 19 07:25:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 22:25:16 -0700 Subject: [ python-Bugs-1467929 ] %-formatting and dicts Message-ID: Bugs item #1467929, was opened at 2006-04-10 19:39 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None >Priority: 8 Submitted By: M.-A. Lemburg (lemburg) Assigned to: Anthony Baxter (anthonybaxter) Summary: %-formatting and dicts Initial Comment: This looks like a bug in the way the %-formatting code works or is it a feature ? >>> '%s %(a)s' % {'a': 'xyz'} "{'a': 'xyz'} xyz" >>> u'%s %(a)s' % {'a': 'xyz'} u"{'a': 'xyz'} xyz" Note that both strings and Unicode are affected. Python 2.3 and 2.4 also show this behavior. I would have expected an exception or the %-formatter simply ignoring the first %s. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-19 05:25 Message: Logged In: YES user_id=849994 I'd say before 2.5 final... ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-18 22:17 Message: Logged In: YES user_id=38388 Should this patch be applied to the 2.5 branch ? And if so, before or after the release of 2.5 ? ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-18 22:01 Message: Logged In: YES user_id=764593 Just a bit of encouragement for checking consistency like this; the explicit error message would have helped with a mistake I made earlier today. For one of several keys, I mistyped it as "(%key)s", and a message about "not enough values" just didn't make sense. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-04 13:26 Message: Logged In: YES user_id=38388 The patch looks OK. I'd make it a TypeError and use "cannot use positional and named formatting parameters at the same time" as message. Thanks. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-08-04 13:21 Message: Logged In: YES user_id=44345 Looks okay to me, though why is the FORMAT_TYPE_UNKNOWN test necessary in the second case but not the first? ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-07-25 12:35 Message: Logged In: YES user_id=11375 So, what should '%s' % {} do? Should it be 1) '{}' or 2) an error because the argument is a mapping but the format specifier doesn't have a '(key)'? I've attached a draft patch that fixes stringobject.c; if the approach is deemed OK, I'll apply it to unicodeobject.c, too. PyString_Format() records the type of argument being processed (a tuple or a mapping) and raises ValueError if you mix them, at the cost of two extra comparisons for each format specifier processed. This preserves the current behaviour of '%s' % dictionary. Questions: 1) is the approach reasonably clear? 2) are the additional two comparisons unacceptably slow? 3) Is ValueError the right exception? 4) can someone come up with a better exception message than "both keyed and unkeyed format specifiers used"? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-07-24 20:07 Message: Logged In: YES user_id=21627 IMO, it's correct to break backwards compatibility, as the current behaviour clearly violates the spec; I'm not sure whether it's good to break the behaviour *now* (i.e. with no further betas before the release of 2.5). Deferring to the release manager. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-24 13:37 Message: Logged In: YES user_id=849994 The library ref specifies that if a dict is supplied, the format specifiers MUST include a mapping key, so the right thing to do would be to raise an exception. Is it worth breaking backwards compatibility, Martin? ---------------------------------------------------------------------- Comment By: Hasan Diwan (hdiwan650) Date: 2006-04-14 08:33 Message: Logged In: YES user_id=1185570 It looks as though it's a feature... The first %s will print the whole dictionary as a string, the second, only that value looked up by the key. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467929&group_id=5470 From noreply at sourceforge.net Sat Aug 19 07:35:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Aug 2006 22:35:32 -0700 Subject: [ python-Bugs-971213 ] another threads+readline+signals nasty Message-ID: Bugs item #971213, was opened at 2004-06-11 15:30 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971213&group_id=5470 Please note that this 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: Works For Me Priority: 7 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Anthony Baxter (anthonybaxter) Summary: another threads+readline+signals nasty Initial Comment: python -c "import time, readline, thread; thread.start_new_thread(raw_input, ()); time.sleep(2)" Segfaults on ^C Fails on Linux, freebsd. On linux (FC - using kernel 2.6.1, glibc 2.3.3, gcc-3.3.3) (gdb) where #0 0x002627a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x008172b1 in ___newselect_nocancel () from /lib/tls/libc.so.6 #2 0x0011280b in time_sleep (self=0x0, args=0xb7fe17ac) at Modules/timemodule.c:815 on FreeBSD 5.2.1-RC, a different error. Fatal error 'longjmp()ing between thread contexts is undefined by POSIX 1003.1' at line 72 in file /usr/src/lib/libc_r/uthread/uthread_jmp.c (errno = 2) Abort (core dumped) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-19 05:35 Message: Logged In: YES user_id=849994 Not reproducable here either (Gentoo x86). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-19 03:09 Message: Logged In: YES user_id=33168 This doesn't crash for me any more. I remember there was another fix for socket timeouts and Ctrl-C. Maybe that fixed this too? Anthony, can you reproduce this? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-10-03 11:13 Message: Logged In: YES user_id=6656 I can't, on OS X or debian. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2005-10-03 04:12 Message: Logged In: YES user_id=33168 I can reproduce with cvs head (gentoo linux/amd64). ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-04-07 09:03 Message: Logged In: YES user_id=6656 I think this is fixed now, as in I can't reproduce it with CVS HEAD. Not sure why! I can think of a few fixes that might be responsible. It still messes the terminal up, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-08-07 21:41 Message: Logged In: YES user_id=6656 Bah, this still segfaults with CVS head. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-21 10:45 Message: Logged In: YES user_id=6656 Can you try the patch that's *now* in 960406? It seems to help for me (but I really would rather not think too hard about this!). ---------------------------------------------------------------------- Comment By: Michal Pasternak (mpasternak) Date: 2004-06-11 15:43 Message: Logged In: YES user_id=799039 readline used on FreeBSD was readline-4.3pl5; everything else: gcc 3.3.3, ncurses, libc were standard from 5.2.1. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2004-06-11 15:39 Message: Logged In: YES user_id=29957 The patch in #960406 doesn't help here. The FC test system also has readline-4.3, if it helps, as does the FreeBSD box. It apparently doesn't crash on OSX. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2004-06-11 15:38 Message: Logged In: YES user_id=6656 Hmm. Doesn't crash on OS X. Messes the terminal up good and proper, though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971213&group_id=5470 From noreply at sourceforge.net Sat Aug 19 12:26:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 19 Aug 2006 03:26:26 -0700 Subject: [ python-Bugs-1536059 ] Missing builtin help for with and as Message-ID: Bugs item #1536059, was opened at 2006-08-07 17:08 Message generated for change (Comment added) made by sgala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536059&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Missing builtin help for with and as Initial Comment: The builtin help system has no results for help('with') and help('as'). This needs to be fixed for 2.6 when the with statement is available by default. The two new keywords will also need to be listed under help('keywords'). ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-19 12:26 Message: Logged In: YES user_id=178886 patch #1542681 tries to fix it ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1536059&group_id=5470 From noreply at sourceforge.net Sun Aug 20 03:48:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 19 Aug 2006 18:48:37 -0700 Subject: [ python-Bugs-1543303 ] tarfile in mode w|gz adds padding that annoys gunzip Message-ID: Bugs item #1543303, was opened at 2006-08-19 22:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543303&group_id=5470 Please note that this 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: alexis (asak) Assigned to: Nobody/Anonymous (nobody) Summary: tarfile in mode w|gz adds padding that annoys gunzip Initial Comment: In mode w|gz tarfile pads the final block with NULs, until its size reaches the bufsize value passed to tarfile.open. This makes gunzip complain about "invalid compressed data" because of CRC and length errors. To reproduce it, put this fragment in a file archive.py import sys import tarfile tar = tarfile.open(mode='w|gz', fileobj=sys.stdout) tar.close() and then: $ python2.5 archive.py | gunzip -c gunzip: stdin: invalid compressed data--crc error gunzip: stdin: invalid compressed data--length error Everything works fine with python 2.3.5 and 2.4.1 on Debian sarge. The padding is added by the following lines in _Stream.close: blocks, remainder = divmod(len(self.buf), self.bufsize) if remainder > 0: self.buf += NUL * (self.bufsize - remainder) They were added in revision 38581, but I'm not sure why - at first sight, "Add tarfile open mode r|*" shouldn't have to change this write path. Removing them makes gunzip happy again, but I have no idea if it breaks something else (test_tarfile doesn't complain). A similar problem happens if you use mode w|bz2 and feed the output to bunzip - it complains about "trailing garbage after EOF ignored". Problems found while running the test suite from the Mercurial SCM. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543303&group_id=5470 From noreply at sourceforge.net Sun Aug 20 04:16:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 19 Aug 2006 19:16:07 -0700 Subject: [ python-Bugs-1543306 ] "from __future__ import foobar; " causes wrong SyntaxError Message-ID: Bugs item #1543306, was opened at 2006-08-20 04:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543306&group_id=5470 Please note that this 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: daniel hahler (blueyed) Assigned to: Nobody/Anonymous (nobody) Summary: "from __future__ import foobar;" causes wrong SyntaxError Initial Comment: Instead of "SyntaxError: future feature foobar is not defined", you will get "SyntaxError: from __future__ imports must occur at the beginning of the file", if you use a semicolon at the end of the line (which is valid for existing future-imports of course). Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from __future__ import foobar; File "", line 1 SyntaxError: from __future__ imports must occur at the beginning of the file >>> from __future__ import generators; >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543306&group_id=5470 From noreply at sourceforge.net Sun Aug 20 06:31:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 19 Aug 2006 21:31:44 -0700 Subject: [ python-Bugs-1377858 ] segfaults when using __del__ and weakrefs Message-ID: Bugs item #1377858, was opened at 2005-12-10 13:20 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Carl Friedrich Bolz (cfbolz) Assigned to: Michael Hudson (mwh) Summary: segfaults when using __del__ and weakrefs Initial Comment: You can segfault Python by creating a weakref to an object in its __del__ method, storing it somewhere and then trying to dereference the weakref afterwards. the attached file shows the described behaviour. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-08-19 21:31 Message: Logged In: YES user_id=357491 After finally figuring out where *list was made NULL (and adding a comment about it where it occurs), I added a test to test_weakref.py . Didn't try to tackle classic classes. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-08-12 04:31 Message: Logged In: YES user_id=4771 The clear_weakref(*list) only clears the first weakref to the object. You need a while loop in your patch. (attached proposed fix) Now we're left with fixing the same bug in old-style classes (surprize surprize), and turning the crasher into a test. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-29 10:36 Message: Logged In: YES user_id=357491 So after staring at this crasher it seemed to me to be that clearing the new weakrefs w/o calling their finalizers after calling the object's finalizer was the best solution. I couldn't think of any other good way to communicate to the new weakrefs that the object they refer to was no longer viable memory without doing clear_weakref() work by hand. Attached is a patch to do this. Michael, can you have a look? ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2006-01-10 11:29 Message: Logged In: YES user_id=1188172 Added to outstanding_crashes.py. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-01-09 03:58 Message: Logged In: YES user_id=6656 Hmm, maybe the referenced mayhem is more to do with clearing __dict__ than calling __del__. What breaks if we do things in this order: 1. call __del__ 2. clear weakrefs 3. clear __dict__ ? ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-01-09 03:54 Message: Logged In: YES user_id=6656 Hmm, I was kind of hoping this report would get more attention. The problem is obvious if you read typeobject.c around line 660: the weakref list is cleared before __del__ is called, so any weakrefs added during the execution of __del__ are never informed of the object's death. One fix for this would be to clear the weakref list _after_ calling __del__ but that led to other mayhem in ways I haven't boethered to understand (see SF bug #742911). I guess we could just clear out any weakrefs created in __del__ without calling their callbacks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377858&group_id=5470 From noreply at sourceforge.net Sun Aug 20 07:59:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 19 Aug 2006 22:59:55 -0700 Subject: [ python-Bugs-1543347 ] Operator precedence inconsistent for complex literal Message-ID: Bugs item #1543347, was opened at 2006-08-20 14:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543347&group_id=5470 Please note that this 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: [N/A] (ymasuda) Assigned to: Nobody/Anonymous (nobody) Summary: Operator precedence inconsistent for complex literal Initial Comment: Using complex, real and imag attributes are computed collectly as follows: >>> 1+2j (1+2j) >>> z = 1+2j >>> z.real 1.0 >>> z.imag 2.0 >>> (1+2j).real 1.0 >>> (1+2j).imag 2.0 But, if there's no explicit literal boundary, it seems to break consistensy in operator precedence: >>> 1+2j.real # addition succeeds j-suffux 1.0 >>> 1+2j.imag # addition precedes (j-suffix and) attribute reference 3.0 >>> 0+1+2j.real # same as above 1.0 >>> 0+1+2j.imag 3.0 >>> 1+0+2j.imag 3.0 >>> 1+0+2j.real 1.0 >>> 1+(2j).imag # brace puts no bless 3.0 >>> 1*1+2j.imag # star fails to steer 3.0 This happens at least on Python 2.3.5 (OSX bundled), Python 2.4.2 (build from ports, FreeBSD 5.4). # Practically, of course, you always explicit (1+2j) to construct complex thus hardly troubled with this :) but it would be happy for beginners to mention it on standard tutorial or something. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543347&group_id=5470 From noreply at sourceforge.net Sun Aug 20 15:18:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 20 Aug 2006 06:18:21 -0700 Subject: [ python-Bugs-1543467 ] test_tempfile fails on cygwin Message-ID: Bugs item #1543467, was opened at 2006-08-20 16: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=1543467&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_tempfile fails on cygwin Initial Comment: This is RC1: [16:07] ~/src/Python-2.5c1 $./python.exe -c 'from test.test_tempfile import test_main; test_main()' test_exports (test.test_tempfile.test_exports) ... ok test_get_six_char_str (test.test_tempfile.test__RandomNameSequence) ... ok test_many (test.test_tempfile.test__RandomNameSequence) ... ok test_supports_iter (test.test_tempfile.test__RandomNameSequence) ... ok test_nonempty_list (test.test_tempfile.test__candidate_tempdir_list) ... ok test_wanted_dirs (test.test_tempfile.test__candidate_tempdir_list) ... ok test_retval (test.test_tempfile.test__get_candidate_names) ... ok test_same_thing (test.test_tempfile.test__get_candidate_names) ... ok test_basic (test.test_tempfile.test__mkstemp_inner) ... ok test_basic_many (test.test_tempfile.test__mkstemp_inner) ... ok test_choose_directory (test.test_tempfile.test__mkstemp_inner) ... ok test_file_mode (test.test_tempfile.test__mkstemp_inner) ... ok test_noinherit (test.test_tempfile.test__mkstemp_inner) ... FAIL test_textmode (test.test_tempfile.test__mkstemp_inner) ... ok test_sane_template (test.test_tempfile.test_gettempprefix) ... ok test_usable_template (test.test_tempfile.test_gettempprefix) ... ok test_directory_exists (test.test_tempfile.test_gettempdir) ... ok test_directory_writable (test.test_tempfile.test_gettempdir) ... ok test_same_thing (test.test_tempfile.test_gettempdir) ... ok test_basic (test.test_tempfile.test_mkstemp) ... ok test_choose_directory (test.test_tempfile.test_mkstemp) ... ok test_basic (test.test_tempfile.test_mkdtemp) ... ok test_basic_many (test.test_tempfile.test_mkdtemp) ... ok test_choose_directory (test.test_tempfile.test_mkdtemp) ... ok test_mode (test.test_tempfile.test_mkdtemp) ... ok test_basic (test.test_tempfile.test_mktemp) ... ok test_many (test.test_tempfile.test_mktemp) ... ok test_basic (test.test_tempfile.test_NamedTemporaryFile) ... ok test_creates_named (test.test_tempfile.test_NamedTemporaryFile) ... ok test_del_on_close (test.test_tempfile.test_NamedTemporaryFile) ... ok test_multiple_close (test.test_tempfile.test_NamedTemporaryFile) ... ok ====================================================================== FAIL: test_noinherit (test.test_tempfile.test__mkstemp_inner) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 127 ---------------------------------------------------------------------- Ran 31 tests in 1.077s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_tempfile.py", line 665, in test_main test_support.run_unittest(*test_classes) File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_support.py", line 441, in run_unittest run_suite(suite, testclass) File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_support.py", line 426, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 127 [16:12] ~/src/Python-2.5c1 $ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543467&group_id=5470 From noreply at sourceforge.net Sun Aug 20 15:22:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 20 Aug 2006 06:22:25 -0700 Subject: [ python-Bugs-1543469 ] test_subprocess fails on cygwin Message-ID: Bugs item #1543469, was opened at 2006-08-20 16:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543469&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_subprocess fails on cygwin Initial Comment: This is RC1. test_subprocess fails. IMO due to the fact that there is a directory called "Python" in the python source directory. The fix should be that sys.executable will return the name with the '.exe' suffix on cygwin. Attached log of running the test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543469&group_id=5470 From noreply at sourceforge.net Sun Aug 20 16:17:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 20 Aug 2006 07:17:06 -0700 Subject: [ python-Bugs-1543303 ] tarfile in mode w|gz adds padding that annoys gunzip Message-ID: Bugs item #1543303, was opened at 2006-08-20 01:48 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543303&group_id=5470 Please note that this 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: 8 Submitted By: alexis (asak) >Assigned to: Neal Norwitz (nnorwitz) Summary: tarfile in mode w|gz adds padding that annoys gunzip Initial Comment: In mode w|gz tarfile pads the final block with NULs, until its size reaches the bufsize value passed to tarfile.open. This makes gunzip complain about "invalid compressed data" because of CRC and length errors. To reproduce it, put this fragment in a file archive.py import sys import tarfile tar = tarfile.open(mode='w|gz', fileobj=sys.stdout) tar.close() and then: $ python2.5 archive.py | gunzip -c gunzip: stdin: invalid compressed data--crc error gunzip: stdin: invalid compressed data--length error Everything works fine with python 2.3.5 and 2.4.1 on Debian sarge. The padding is added by the following lines in _Stream.close: blocks, remainder = divmod(len(self.buf), self.bufsize) if remainder > 0: self.buf += NUL * (self.bufsize - remainder) They were added in revision 38581, but I'm not sure why - at first sight, "Add tarfile open mode r|*" shouldn't have to change this write path. Removing them makes gunzip happy again, but I have no idea if it breaks something else (test_tarfile doesn't complain). A similar problem happens if you use mode w|bz2 and feed the output to bunzip - it complains about "trailing garbage after EOF ignored". Problems found while running the test suite from the Mercurial SCM. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-20 14:17 Message: Logged In: YES user_id=849994 This should be resolved before 2.5 final. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543303&group_id=5470 From noreply at sourceforge.net Sun Aug 20 16:33:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 20 Aug 2006 07:33:21 -0700 Subject: [ python-Bugs-1543306 ] "from __future__ import foobar; " causes wrong SyntaxError Message-ID: Bugs item #1543306, was opened at 2006-08-20 02:16 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543306&group_id=5470 Please note that this 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: 3 Submitted By: daniel hahler (blueyed) Assigned to: Nobody/Anonymous (nobody) Summary: "from __future__ import foobar;" causes wrong SyntaxError Initial Comment: Instead of "SyntaxError: future feature foobar is not defined", you will get "SyntaxError: from __future__ imports must occur at the beginning of the file", if you use a semicolon at the end of the line (which is valid for existing future-imports of course). Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from __future__ import foobar; File "", line 1 SyntaxError: from __future__ imports must occur at the beginning of the file >>> from __future__ import generators; >>> ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-20 14:33 Message: Logged In: YES user_id=849994 The 2.5+ AST compiler gives the correct error message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543306&group_id=5470 From noreply at sourceforge.net Sun Aug 20 16:37:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 20 Aug 2006 07:37:26 -0700 Subject: [ python-Bugs-1543347 ] Operator precedence inconsistent for complex literal Message-ID: Bugs item #1543347, was opened at 2006-08-20 05:59 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543347&group_id=5470 Please note that this 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: Works For Me Priority: 5 Submitted By: [N/A] (ymasuda) Assigned to: Nobody/Anonymous (nobody) Summary: Operator precedence inconsistent for complex literal Initial Comment: Using complex, real and imag attributes are computed collectly as follows: >>> 1+2j (1+2j) >>> z = 1+2j >>> z.real 1.0 >>> z.imag 2.0 >>> (1+2j).real 1.0 >>> (1+2j).imag 2.0 But, if there's no explicit literal boundary, it seems to break consistensy in operator precedence: >>> 1+2j.real # addition succeeds j-suffux 1.0 >>> 1+2j.imag # addition precedes (j-suffix and) attribute reference 3.0 >>> 0+1+2j.real # same as above 1.0 >>> 0+1+2j.imag 3.0 >>> 1+0+2j.imag 3.0 >>> 1+0+2j.real 1.0 >>> 1+(2j).imag # brace puts no bless 3.0 >>> 1*1+2j.imag # star fails to steer 3.0 This happens at least on Python 2.3.5 (OSX bundled), Python 2.4.2 (build from ports, FreeBSD 5.4). # Practically, of course, you always explicit (1+2j) to construct complex thus hardly troubled with this :) but it would be happy for beginners to mention it on standard tutorial or something. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-20 14:37 Message: Logged In: YES user_id=849994 I can't see anything inconsistent here. Attribute access always happens before "+" or "*" are applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543347&group_id=5470 From noreply at sourceforge.net Sun Aug 20 18:52:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 20 Aug 2006 09:52:21 -0700 Subject: [ python-Bugs-1543347 ] Operator precedence inconsistent for complex literal Message-ID: Bugs item #1543347, was opened at 2006-08-20 01:59 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543347&group_id=5470 Please note that this 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: Works For Me Priority: 5 Submitted By: [N/A] (ymasuda) Assigned to: Nobody/Anonymous (nobody) Summary: Operator precedence inconsistent for complex literal Initial Comment: Using complex, real and imag attributes are computed collectly as follows: >>> 1+2j (1+2j) >>> z = 1+2j >>> z.real 1.0 >>> z.imag 2.0 >>> (1+2j).real 1.0 >>> (1+2j).imag 2.0 But, if there's no explicit literal boundary, it seems to break consistensy in operator precedence: >>> 1+2j.real # addition succeeds j-suffux 1.0 >>> 1+2j.imag # addition precedes (j-suffix and) attribute reference 3.0 >>> 0+1+2j.real # same as above 1.0 >>> 0+1+2j.imag 3.0 >>> 1+0+2j.imag 3.0 >>> 1+0+2j.real 1.0 >>> 1+(2j).imag # brace puts no bless 3.0 >>> 1*1+2j.imag # star fails to steer 3.0 This happens at least on Python 2.3.5 (OSX bundled), Python 2.4.2 (build from ports, FreeBSD 5.4). # Practically, of course, you always explicit (1+2j) to construct complex thus hardly troubled with this :) but it would be happy for beginners to mention it on standard tutorial or something. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-08-20 12:52 Message: Logged In: YES user_id=31435 Note that Python doesn't have complex literals, only imaginary literals: 1+2j is the integer 1 added to the imaginary literal 2j. IOW, it's the same as (1)+(2j) = 1 + complex(0, 2). Everything follows from that; e.g., 0+1+2j.imag is parsed as (0+1)+(2j.imag) = 1 + 2.0 = 3.0. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-20 10:37 Message: Logged In: YES user_id=849994 I can't see anything inconsistent here. Attribute access always happens before "+" or "*" are applied. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543347&group_id=5470 From noreply at sourceforge.net Mon Aug 21 04:13:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 20 Aug 2006 19:13:28 -0700 Subject: [ python-Bugs-1543467 ] test_tempfile fails on cygwin Message-ID: Bugs item #1543467, was opened at 2006-08-20 06:18 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543467&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_tempfile fails on cygwin Initial Comment: This is RC1: [16:07] ~/src/Python-2.5c1 $./python.exe -c 'from test.test_tempfile import test_main; test_main()' test_exports (test.test_tempfile.test_exports) ... ok test_get_six_char_str (test.test_tempfile.test__RandomNameSequence) ... ok test_many (test.test_tempfile.test__RandomNameSequence) ... ok test_supports_iter (test.test_tempfile.test__RandomNameSequence) ... ok test_nonempty_list (test.test_tempfile.test__candidate_tempdir_list) ... ok test_wanted_dirs (test.test_tempfile.test__candidate_tempdir_list) ... ok test_retval (test.test_tempfile.test__get_candidate_names) ... ok test_same_thing (test.test_tempfile.test__get_candidate_names) ... ok test_basic (test.test_tempfile.test__mkstemp_inner) ... ok test_basic_many (test.test_tempfile.test__mkstemp_inner) ... ok test_choose_directory (test.test_tempfile.test__mkstemp_inner) ... ok test_file_mode (test.test_tempfile.test__mkstemp_inner) ... ok test_noinherit (test.test_tempfile.test__mkstemp_inner) ... FAIL test_textmode (test.test_tempfile.test__mkstemp_inner) ... ok test_sane_template (test.test_tempfile.test_gettempprefix) ... ok test_usable_template (test.test_tempfile.test_gettempprefix) ... ok test_directory_exists (test.test_tempfile.test_gettempdir) ... ok test_directory_writable (test.test_tempfile.test_gettempdir) ... ok test_same_thing (test.test_tempfile.test_gettempdir) ... ok test_basic (test.test_tempfile.test_mkstemp) ... ok test_choose_directory (test.test_tempfile.test_mkstemp) ... ok test_basic (test.test_tempfile.test_mkdtemp) ... ok test_basic_many (test.test_tempfile.test_mkdtemp) ... ok test_choose_directory (test.test_tempfile.test_mkdtemp) ... ok test_mode (test.test_tempfile.test_mkdtemp) ... ok test_basic (test.test_tempfile.test_mktemp) ... ok test_many (test.test_tempfile.test_mktemp) ... ok test_basic (test.test_tempfile.test_NamedTemporaryFile) ... ok test_creates_named (test.test_tempfile.test_NamedTemporaryFile) ... ok test_del_on_close (test.test_tempfile.test_NamedTemporaryFile) ... ok test_multiple_close (test.test_tempfile.test_NamedTemporaryFile) ... ok ====================================================================== FAIL: test_noinherit (test.test_tempfile.test__mkstemp_inner) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 127 ---------------------------------------------------------------------- Ran 31 tests in 1.077s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_tempfile.py", line 665, in test_main test_support.run_unittest(*test_classes) File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_support.py", line 441, in run_unittest run_suite(suite, testclass) File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_support.py", line 426, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 127 [16:12] ~/src/Python-2.5c1 $ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-20 19:13 Message: Logged In: YES user_id=33168 What version of cygwin? I've been testing with 1.5.19 and greater and not had this problem. However, I've only run with regrtest. Do you have this problem only if running directly? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543467&group_id=5470 From noreply at sourceforge.net Mon Aug 21 04:15:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 20 Aug 2006 19:15:13 -0700 Subject: [ python-Bugs-1543469 ] test_subprocess fails on cygwin Message-ID: Bugs item #1543469, was opened at 2006-08-20 06:22 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543469&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_subprocess fails on cygwin Initial Comment: This is RC1. test_subprocess fails. IMO due to the fact that there is a directory called "Python" in the python source directory. The fix should be that sys.executable will return the name with the '.exe' suffix on cygwin. Attached log of running the test. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-20 19:15 Message: Logged In: YES user_id=33168 Cygwin recently changed their behaviour. I have an outstanding hack to fix this. Patches would help get things fixed up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543469&group_id=5470 From noreply at sourceforge.net Mon Aug 21 07:55:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 20 Aug 2006 22:55:09 -0700 Subject: [ python-Bugs-1543467 ] test_tempfile fails on cygwin Message-ID: Bugs item #1543467, was opened at 2006-08-20 16:18 Message generated for change (Comment added) made by tebeka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543467&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_tempfile fails on cygwin Initial Comment: This is RC1: [16:07] ~/src/Python-2.5c1 $./python.exe -c 'from test.test_tempfile import test_main; test_main()' test_exports (test.test_tempfile.test_exports) ... ok test_get_six_char_str (test.test_tempfile.test__RandomNameSequence) ... ok test_many (test.test_tempfile.test__RandomNameSequence) ... ok test_supports_iter (test.test_tempfile.test__RandomNameSequence) ... ok test_nonempty_list (test.test_tempfile.test__candidate_tempdir_list) ... ok test_wanted_dirs (test.test_tempfile.test__candidate_tempdir_list) ... ok test_retval (test.test_tempfile.test__get_candidate_names) ... ok test_same_thing (test.test_tempfile.test__get_candidate_names) ... ok test_basic (test.test_tempfile.test__mkstemp_inner) ... ok test_basic_many (test.test_tempfile.test__mkstemp_inner) ... ok test_choose_directory (test.test_tempfile.test__mkstemp_inner) ... ok test_file_mode (test.test_tempfile.test__mkstemp_inner) ... ok test_noinherit (test.test_tempfile.test__mkstemp_inner) ... FAIL test_textmode (test.test_tempfile.test__mkstemp_inner) ... ok test_sane_template (test.test_tempfile.test_gettempprefix) ... ok test_usable_template (test.test_tempfile.test_gettempprefix) ... ok test_directory_exists (test.test_tempfile.test_gettempdir) ... ok test_directory_writable (test.test_tempfile.test_gettempdir) ... ok test_same_thing (test.test_tempfile.test_gettempdir) ... ok test_basic (test.test_tempfile.test_mkstemp) ... ok test_choose_directory (test.test_tempfile.test_mkstemp) ... ok test_basic (test.test_tempfile.test_mkdtemp) ... ok test_basic_many (test.test_tempfile.test_mkdtemp) ... ok test_choose_directory (test.test_tempfile.test_mkdtemp) ... ok test_mode (test.test_tempfile.test_mkdtemp) ... ok test_basic (test.test_tempfile.test_mktemp) ... ok test_many (test.test_tempfile.test_mktemp) ... ok test_basic (test.test_tempfile.test_NamedTemporaryFile) ... ok test_creates_named (test.test_tempfile.test_NamedTemporaryFile) ... ok test_del_on_close (test.test_tempfile.test_NamedTemporaryFile) ... ok test_multiple_close (test.test_tempfile.test_NamedTemporaryFile) ... ok ====================================================================== FAIL: test_noinherit (test.test_tempfile.test__mkstemp_inner) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 127 ---------------------------------------------------------------------- Ran 31 tests in 1.077s FAILED (failures=1) Traceback (most recent call last): File "", line 1, in File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_tempfile.py", line 665, in test_main test_support.run_unittest(*test_classes) File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_support.py", line 441, in run_unittest run_suite(suite, testclass) File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_support.py", line 426, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/home/mtebeka/src/Python-2.5c1/Lib/test/test_tempfile.py", line 310, in test_noinherit self.failIf(retval > 0, "child process reports failure %d"%retval) AssertionError: child process reports failure 127 [16:12] ~/src/Python-2.5c1 $ ---------------------------------------------------------------------- >Comment By: Miki Tebeka (tebeka) Date: 2006-08-21 08:55 Message: Logged In: YES user_id=358087 Cygwin version is 1.5.21 (see attached output of cygcheck -s -v -r). What do you mean by "running directly"? I ran the test with the following command line (and it failed): ./python.exe -c 'from test.test_tempfile import test_main; test_main()' ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 05:13 Message: Logged In: YES user_id=33168 What version of cygwin? I've been testing with 1.5.19 and greater and not had this problem. However, I've only run with regrtest. Do you have this problem only if running directly? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543467&group_id=5470 From noreply at sourceforge.net Mon Aug 21 09:55:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 00:55:17 -0700 Subject: [ python-Bugs-1528802 ] Turkish Character Message-ID: Bugs item #1528802, was opened at 2006-07-26 10:05 Message generated for change (Comment added) made by ahmetbiskinler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 Please note that this 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.5 Status: Open Resolution: None >Priority: 7 Submitted By: Ahmet Bi?kinler (ahmetbiskinler) Assigned to: M.-A. Lemburg (lemburg) Summary: Turkish Character Initial Comment: >>> print "May?s".upper() >>> MAY?S >>> import locale >>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254') >>> print "May?s".upper() >>> MAY?S >>> print "???i???".upper() >>> ???I??? MAY?S should be MAYIS ???I??? should be ??????I but >>> "May?s".upper() >>> "MAYIS" is right ---------------------------------------------------------------------- >Comment By: Ahmet Bi?kinler (ahmetbiskinler) Date: 2006-08-21 10:55 Message: Logged In: YES user_id=1481281 There are still some problems with it. As in the image. http://img205.imageshack.us/img205/3998/turkishcharpythonyu5.jpg The upper() works fine(except ? and i uppercase) with IDLE since upper() doesn't even work. Another problem is with the ?(dotless) and i(dotted) 's upper. ?(dotless) should be I (dotless) i(dotted) should be ? (dotted) ? = I i = ? For more information: http://www.i18nguy.com/unicode/turkish-i18n.html ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-18 17:37 Message: Logged In: YES user_id=178886 Done: Bug #1542677 ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 22:08 Message: Logged In: YES user_id=849994 Please submit that as a separate IDLE bug. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 21:58 Message: Logged In: YES user_id=178886 Idle from 2.5rc1 (svn today) produces a different result than console (with my default, utf-8, encoding): IDLE 1.2c1 >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ?? >>> print len(u"?") 2 >>> print u"?".upper() ?? >>> str(u"?") Traceback (most recent call last): File "", line 1, in str(u"?") UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128) Again, IDLE 1.1.3 (python 2.4.3) produces a different result: IDLE 1.1.3 >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ?? >>> print len(u"?") 2 >>> print u"?".upper() ?? >>> str(u"?") '\xc3\x83\xc2\xa1' >>> I'd say idle is broken, as it is not able to respect utf-8 for print (or even len) of unicode strings. OTOH, with some tricks I can manage to get an accented a in a unicode in idle: >>> import unicodedata >>> print unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE") ? >>> print len(unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE")) 1 ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 18:08 Message: Logged In: YES user_id=849994 Using Unicode strings, the OP's example works. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-17 18:04 Message: Logged In: YES user_id=38388 String upper and lower conversion are locale dependent and implemented by the underlying libc, whereas Unicode upper/lower conversion is not and only depends on the Unicode character database. OTOH, there are special cases where the standard Unicode upper/lower mapping is no what you might expect, since the database only provides a single mapping and is not context aware. There's nothing we can do if the libc is broken in some respect. As for the extended case mapping support in Unicode: patches are welcome. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 18:03 Message: Logged In: YES user_id=849994 sgala: it looks like your console sends UTF-8 encoded text. >>> print "?" ? print is just printing out a byte string consisting of two bytes, which your console displays as accent-a. >>> print len("?") 2 A UTF-8-encoded string containing an accented a has two bytes. >>> print "?".upper() ? str.upper() doesn't take locale into account, so the accented a has no uppercase version defined. >>> str("?") '\xc3\xa1' str() applied to a byte string returns that byte string. Since return values from functions are printed by the interactive interpreter using repr() first, you get this representation (which you could also get from "print repr('a')".) >>> print u"?" ? That's also okay. Python knows the terminal encoding and properly translates the byte string to a unicode string of one character. On printout, it converts it to a UTF-8 string again, which your terminal displays correctly. >>> print len(u"?") 1 Since your two-byte-UTF-8 sequence is converted to a unicode character, the length of this unicode string is 1. >>> print u"?".upper() ? There are comprehensive capitalization tables available for unicode. >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) Applying str() to a unicode string must convert it to a byte string. If you don't specify an encoding, the default encoding is "ascii", which can't encode the accented a. Use "a".encode("utf-8"). ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 17:59 Message: Logged In: YES user_id=178886 (I tested it in 2.5rc1), 2.4 gives >>> str(u"?") '\xc3\xa1' instead of the exception ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 17:53 Message: Logged In: YES user_id=178886 The behaviour of python in this area is confusing. See a session with my Spanish keyboard: >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ? >>> print len(u"?") 1 >>> print u"?".upper() ? >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) I guess this is what is happening to the reporter. This violates the least surprising behavior principle in so many different ways that it hurts. Can anybody make sense of it? ---------------------------------------------------------------------- Comment By: Ahmet Bi?kinler (ahmetbiskinler) Date: 2006-08-11 11:10 Message: Logged In: YES user_id=1481281 What happened? Is it solved? How is it going? What is the final step? ...? ...? Could you please give me some information about the bug please? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 From noreply at sourceforge.net Mon Aug 21 10:07:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 01:07:06 -0700 Subject: [ python-Bugs-1543469 ] test_subprocess fails on cygwin Message-ID: Bugs item #1543469, was opened at 2006-08-20 06:22 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543469&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_subprocess fails on cygwin Initial Comment: This is RC1. test_subprocess fails. IMO due to the fact that there is a directory called "Python" in the python source directory. The fix should be that sys.executable will return the name with the '.exe' suffix on cygwin. Attached log of running the test. ---------------------------------------------------------------------- >Comment By: Nobody/Anonymous (nobody) Date: 2006-08-21 01:07 Message: Logged In: NO Attached a patch, test_subprocess now passes. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-20 19:15 Message: Logged In: YES user_id=33168 Cygwin recently changed their behaviour. I have an outstanding hack to fix this. Patches would help get things fixed up. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543469&group_id=5470 From noreply at sourceforge.net Mon Aug 21 10:21:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 01:21:06 -0700 Subject: [ python-Bugs-1543801 ] md5 sums are different between Solaris and Windows XP SP1 Message-ID: Bugs item #1543801, was opened at 2006-08-21 10: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=1543801&group_id=5470 Please note that this 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: Stefan Sonnenberg (sunmountain) Assigned to: Nobody/Anonymous (nobody) Summary: md5 sums are different between Solaris and Windows XP SP1 Initial Comment: The following program produces different md5 sums under Solaris and Windows XP, but sums are equal under the same platform. #!/opt/ASpy23/bin/python import sys import md5 import getopt import os import re try: opts,args = getopt.getopt(sys.argv[1:],'c:f:h') except getopt.GetoptError,e: print 'Parsing command line arguments failed. (%s)' % str(e) sys.exit(1) md5file = None fname = None for o,a in opts: if o in '-c': if fname is not None: print '-c and -f are mutually exclusive' sys.exit(1) md5file = a if o in '-f': if md5file is not None: print '-c and -f are mutually exclusive' sys.exit(1) fname = a if o in '-h': print 'Usage: md5 filename. (%s)' % str(e) sys.exit(1) if md5file is not None and os.path.isfile(md5file): try: lines = open(md5file,'r').readlines() except IOError,e: print 'Could not read MD5 sum file %s. (%s)' % (md5file,str(e)) sys.exit(1) for line in lines: line = line[:-1] try: res = re.compile('MD5[ |\t]+\((.+)\)[ |\t]+?\=[ |\t]+(.+)').findall(line)[0] except Exception,e: print 'Could not parse line. (%s)' % str(e) sys.exit(1) if os.path.isfile(res[0]): try: f = open(res[0],'r') except IOError,e: print 'Could not open file %s. (%s)' % (res[0],str(e)) sys.exit(1) sum = md5.new() try: sum.update(f.read()) except Exception,e: print 'Could not update MD5 sum. (%s)' % str(e) sys.exit(1) #print sum.hexdigest(),res[1][2:],res[0],line if sum.hexdigest() == res[1][2:]: print 'MD5 sum of file %s is OK' % res[0] else: print 'MD5 sum of file %s DIFFERS' % res[0] f.close() sum = None sys.exit(0) sum = md5.new() try: f = open(fname,'r') except IOError,e: print 'Could not open %s. (%s)' % ( fname,str(e) ) try: sum.update(f.read()) except Exception,e: print 'Could not update md5 sum. (%s)' % str(e) print 'MD5 (%s) = 0x%s' % (fname,sum.hexdigest()) f.close() Python version Solaris: Python 2.3.5 (#1, Feb 9 2005, 14:45:39) [C] on sunos5 Python version Windows XP: Python 2.3.5 (#62, Feb 9 2005, 16:17:08) [MSC v.1200 32 bit (Intel)] on win32 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543801&group_id=5470 From noreply at sourceforge.net Mon Aug 21 11:06:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 02:06:24 -0700 Subject: [ python-Bugs-1543801 ] md5 sums are different between Solaris and Windows XP SP1 Message-ID: Bugs item #1543801, was opened at 2006-08-21 08:21 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543801&group_id=5470 Please note that this 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: Pending Resolution: None Priority: 5 Submitted By: Stefan Sonnenberg (sunmountain) Assigned to: Nobody/Anonymous (nobody) Summary: md5 sums are different between Solaris and Windows XP SP1 Initial Comment: The following program produces different md5 sums under Solaris and Windows XP, but sums are equal under the same platform. #!/opt/ASpy23/bin/python import sys import md5 import getopt import os import re try: opts,args = getopt.getopt(sys.argv[1:],'c:f:h') except getopt.GetoptError,e: print 'Parsing command line arguments failed. (%s)' % str(e) sys.exit(1) md5file = None fname = None for o,a in opts: if o in '-c': if fname is not None: print '-c and -f are mutually exclusive' sys.exit(1) md5file = a if o in '-f': if md5file is not None: print '-c and -f are mutually exclusive' sys.exit(1) fname = a if o in '-h': print 'Usage: md5 filename. (%s)' % str(e) sys.exit(1) if md5file is not None and os.path.isfile(md5file): try: lines = open(md5file,'r').readlines() except IOError,e: print 'Could not read MD5 sum file %s. (%s)' % (md5file,str(e)) sys.exit(1) for line in lines: line = line[:-1] try: res = re.compile('MD5[ |\t]+\((.+)\)[ |\t]+?\=[ |\t]+(.+)').findall(line)[0] except Exception,e: print 'Could not parse line. (%s)' % str(e) sys.exit(1) if os.path.isfile(res[0]): try: f = open(res[0],'r') except IOError,e: print 'Could not open file %s. (%s)' % (res[0],str(e)) sys.exit(1) sum = md5.new() try: sum.update(f.read()) except Exception,e: print 'Could not update MD5 sum. (%s)' % str(e) sys.exit(1) #print sum.hexdigest(),res[1][2:],res[0],line if sum.hexdigest() == res[1][2:]: print 'MD5 sum of file %s is OK' % res[0] else: print 'MD5 sum of file %s DIFFERS' % res[0] f.close() sum = None sys.exit(0) sum = md5.new() try: f = open(fname,'r') except IOError,e: print 'Could not open %s. (%s)' % ( fname,str(e) ) try: sum.update(f.read()) except Exception,e: print 'Could not update md5 sum. (%s)' % str(e) print 'MD5 (%s) = 0x%s' % (fname,sum.hexdigest()) f.close() Python version Solaris: Python 2.3.5 (#1, Feb 9 2005, 14:45:39) [C] on sunos5 Python version Windows XP: Python 2.3.5 (#62, Feb 9 2005, 16:17:08) [MSC v.1200 32 bit (Intel)] on win32 ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-21 09:06 Message: Logged In: YES user_id=849994 You're opening files in text mode, which is likely to return different file contents on Windows and Unix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543801&group_id=5470 From noreply at sourceforge.net Mon Aug 21 11:06:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 02:06:33 -0700 Subject: [ python-Bugs-1543801 ] md5 sums are different between Solaris and Windows XP SP1 Message-ID: Bugs item #1543801, was opened at 2006-08-21 10:21 Message generated for change (Comment added) made by sunmountain You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543801&group_id=5470 Please note that this 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: Stefan Sonnenberg (sunmountain) Assigned to: Nobody/Anonymous (nobody) Summary: md5 sums are different between Solaris and Windows XP SP1 Initial Comment: The following program produces different md5 sums under Solaris and Windows XP, but sums are equal under the same platform. #!/opt/ASpy23/bin/python import sys import md5 import getopt import os import re try: opts,args = getopt.getopt(sys.argv[1:],'c:f:h') except getopt.GetoptError,e: print 'Parsing command line arguments failed. (%s)' % str(e) sys.exit(1) md5file = None fname = None for o,a in opts: if o in '-c': if fname is not None: print '-c and -f are mutually exclusive' sys.exit(1) md5file = a if o in '-f': if md5file is not None: print '-c and -f are mutually exclusive' sys.exit(1) fname = a if o in '-h': print 'Usage: md5 filename. (%s)' % str(e) sys.exit(1) if md5file is not None and os.path.isfile(md5file): try: lines = open(md5file,'r').readlines() except IOError,e: print 'Could not read MD5 sum file %s. (%s)' % (md5file,str(e)) sys.exit(1) for line in lines: line = line[:-1] try: res = re.compile('MD5[ |\t]+\((.+)\)[ |\t]+?\=[ |\t]+(.+)').findall(line)[0] except Exception,e: print 'Could not parse line. (%s)' % str(e) sys.exit(1) if os.path.isfile(res[0]): try: f = open(res[0],'r') except IOError,e: print 'Could not open file %s. (%s)' % (res[0],str(e)) sys.exit(1) sum = md5.new() try: sum.update(f.read()) except Exception,e: print 'Could not update MD5 sum. (%s)' % str(e) sys.exit(1) #print sum.hexdigest(),res[1][2:],res[0],line if sum.hexdigest() == res[1][2:]: print 'MD5 sum of file %s is OK' % res[0] else: print 'MD5 sum of file %s DIFFERS' % res[0] f.close() sum = None sys.exit(0) sum = md5.new() try: f = open(fname,'r') except IOError,e: print 'Could not open %s. (%s)' % ( fname,str(e) ) try: sum.update(f.read()) except Exception,e: print 'Could not update md5 sum. (%s)' % str(e) print 'MD5 (%s) = 0x%s' % (fname,sum.hexdigest()) f.close() Python version Solaris: Python 2.3.5 (#1, Feb 9 2005, 14:45:39) [C] on sunos5 Python version Windows XP: Python 2.3.5 (#62, Feb 9 2005, 16:17:08) [MSC v.1200 32 bit (Intel)] on win32 ---------------------------------------------------------------------- >Comment By: Stefan Sonnenberg (sunmountain) Date: 2006-08-21 11:06 Message: Logged In: YES user_id=1575341 I double checked the behaviour. With Python the md5 sums differ between Solaris and Windows. Using external tools for generating md5 sums, these are always equal, under both systems, as it should be with md5. I did not try other python versions. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-21 11:06 Message: Logged In: YES user_id=849994 You're opening files in text mode, which is likely to return different file contents on Windows and Unix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543801&group_id=5470 From noreply at sourceforge.net Mon Aug 21 11:07:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 02:07:16 -0700 Subject: [ python-Bugs-1543801 ] md5 sums are different between Solaris and Windows XP SP1 Message-ID: Bugs item #1543801, was opened at 2006-08-21 08:21 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543801&group_id=5470 Please note that this 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: Pending Resolution: None Priority: 5 Submitted By: Stefan Sonnenberg (sunmountain) Assigned to: Nobody/Anonymous (nobody) Summary: md5 sums are different between Solaris and Windows XP SP1 Initial Comment: The following program produces different md5 sums under Solaris and Windows XP, but sums are equal under the same platform. #!/opt/ASpy23/bin/python import sys import md5 import getopt import os import re try: opts,args = getopt.getopt(sys.argv[1:],'c:f:h') except getopt.GetoptError,e: print 'Parsing command line arguments failed. (%s)' % str(e) sys.exit(1) md5file = None fname = None for o,a in opts: if o in '-c': if fname is not None: print '-c and -f are mutually exclusive' sys.exit(1) md5file = a if o in '-f': if md5file is not None: print '-c and -f are mutually exclusive' sys.exit(1) fname = a if o in '-h': print 'Usage: md5 filename. (%s)' % str(e) sys.exit(1) if md5file is not None and os.path.isfile(md5file): try: lines = open(md5file,'r').readlines() except IOError,e: print 'Could not read MD5 sum file %s. (%s)' % (md5file,str(e)) sys.exit(1) for line in lines: line = line[:-1] try: res = re.compile('MD5[ |\t]+\((.+)\)[ |\t]+?\=[ |\t]+(.+)').findall(line)[0] except Exception,e: print 'Could not parse line. (%s)' % str(e) sys.exit(1) if os.path.isfile(res[0]): try: f = open(res[0],'r') except IOError,e: print 'Could not open file %s. (%s)' % (res[0],str(e)) sys.exit(1) sum = md5.new() try: sum.update(f.read()) except Exception,e: print 'Could not update MD5 sum. (%s)' % str(e) sys.exit(1) #print sum.hexdigest(),res[1][2:],res[0],line if sum.hexdigest() == res[1][2:]: print 'MD5 sum of file %s is OK' % res[0] else: print 'MD5 sum of file %s DIFFERS' % res[0] f.close() sum = None sys.exit(0) sum = md5.new() try: f = open(fname,'r') except IOError,e: print 'Could not open %s. (%s)' % ( fname,str(e) ) try: sum.update(f.read()) except Exception,e: print 'Could not update md5 sum. (%s)' % str(e) print 'MD5 (%s) = 0x%s' % (fname,sum.hexdigest()) f.close() Python version Solaris: Python 2.3.5 (#1, Feb 9 2005, 14:45:39) [C] on sunos5 Python version Windows XP: Python 2.3.5 (#62, Feb 9 2005, 16:17:08) [MSC v.1200 32 bit (Intel)] on win32 ---------------------------------------------------------------------- Comment By: Stefan Sonnenberg (sunmountain) Date: 2006-08-21 09:06 Message: Logged In: YES user_id=1575341 I double checked the behaviour. With Python the md5 sums differ between Solaris and Windows. Using external tools for generating md5 sums, these are always equal, under both systems, as it should be with md5. I did not try other python versions. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-21 09:06 Message: Logged In: YES user_id=849994 You're opening files in text mode, which is likely to return different file contents on Windows and Unix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543801&group_id=5470 From noreply at sourceforge.net Mon Aug 21 11:13:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 02:13:52 -0700 Subject: [ python-Bugs-1543801 ] md5 sums are different between Solaris and Windows XP SP1 Message-ID: Bugs item #1543801, was opened at 2006-08-21 10:21 Message generated for change (Settings changed) made by sunmountain You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543801&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stefan Sonnenberg (sunmountain) Assigned to: Nobody/Anonymous (nobody) Summary: md5 sums are different between Solaris and Windows XP SP1 Initial Comment: The following program produces different md5 sums under Solaris and Windows XP, but sums are equal under the same platform. #!/opt/ASpy23/bin/python import sys import md5 import getopt import os import re try: opts,args = getopt.getopt(sys.argv[1:],'c:f:h') except getopt.GetoptError,e: print 'Parsing command line arguments failed. (%s)' % str(e) sys.exit(1) md5file = None fname = None for o,a in opts: if o in '-c': if fname is not None: print '-c and -f are mutually exclusive' sys.exit(1) md5file = a if o in '-f': if md5file is not None: print '-c and -f are mutually exclusive' sys.exit(1) fname = a if o in '-h': print 'Usage: md5 filename. (%s)' % str(e) sys.exit(1) if md5file is not None and os.path.isfile(md5file): try: lines = open(md5file,'r').readlines() except IOError,e: print 'Could not read MD5 sum file %s. (%s)' % (md5file,str(e)) sys.exit(1) for line in lines: line = line[:-1] try: res = re.compile('MD5[ |\t]+\((.+)\)[ |\t]+?\=[ |\t]+(.+)').findall(line)[0] except Exception,e: print 'Could not parse line. (%s)' % str(e) sys.exit(1) if os.path.isfile(res[0]): try: f = open(res[0],'r') except IOError,e: print 'Could not open file %s. (%s)' % (res[0],str(e)) sys.exit(1) sum = md5.new() try: sum.update(f.read()) except Exception,e: print 'Could not update MD5 sum. (%s)' % str(e) sys.exit(1) #print sum.hexdigest(),res[1][2:],res[0],line if sum.hexdigest() == res[1][2:]: print 'MD5 sum of file %s is OK' % res[0] else: print 'MD5 sum of file %s DIFFERS' % res[0] f.close() sum = None sys.exit(0) sum = md5.new() try: f = open(fname,'r') except IOError,e: print 'Could not open %s. (%s)' % ( fname,str(e) ) try: sum.update(f.read()) except Exception,e: print 'Could not update md5 sum. (%s)' % str(e) print 'MD5 (%s) = 0x%s' % (fname,sum.hexdigest()) f.close() Python version Solaris: Python 2.3.5 (#1, Feb 9 2005, 14:45:39) [C] on sunos5 Python version Windows XP: Python 2.3.5 (#62, Feb 9 2005, 16:17:08) [MSC v.1200 32 bit (Intel)] on win32 ---------------------------------------------------------------------- Comment By: Stefan Sonnenberg (sunmountain) Date: 2006-08-21 11:06 Message: Logged In: YES user_id=1575341 I double checked the behaviour. With Python the md5 sums differ between Solaris and Windows. Using external tools for generating md5 sums, these are always equal, under both systems, as it should be with md5. I did not try other python versions. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-21 11:06 Message: Logged In: YES user_id=849994 You're opening files in text mode, which is likely to return different file contents on Windows and Unix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543801&group_id=5470 From noreply at sourceforge.net Mon Aug 21 12:01:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 03:01:29 -0700 Subject: [ python-Bugs-1528802 ] Turkish Character Message-ID: Bugs item #1528802, was opened at 2006-07-26 09:05 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 Please note that this 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.5 Status: Open Resolution: None >Priority: 5 Submitted By: Ahmet Bi?kinler (ahmetbiskinler) Assigned to: M.-A. Lemburg (lemburg) Summary: Turkish Character Initial Comment: >>> print "May?s".upper() >>> MAY?S >>> import locale >>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254') >>> print "May?s".upper() >>> MAY?S >>> print "???i???".upper() >>> ???I??? MAY?S should be MAYIS ???I??? should be ??????I but >>> "May?s".upper() >>> "MAYIS" is right ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-21 12:01 Message: Logged In: YES user_id=38388 Could we please get some things straight first: 1. if you're working with IDLE and it doesn't do what you expect it to, please file an IDLE bug report, not a Python one; the same it true for any other Python IDE you are using 2. string's .lower() and .upper() method rely 100% on the platform's C lib implementation of these functions; there's nothing Python can do about bugs in these implementations 3. if you want reproducable behavior across platforms, please always use Unicode, *not* 8-bit strings, for text data. I see that #1 has already been done, so the IDLE specific discussion should continue there. #2 is the cause of the problem, then all we can do is point you to #3. If #3 fails for some reason, then we should investigate this. However, be aware that the Unicode database has a fixed set of case mappings and we currently don't support extended case mapping which is locale and context sensitive. Again, patches are welcome. Please provide your examples using the repr() of the string or Unicode objects in question. This makes it a lot easier to test your examples on other platforms. Thanks. ---------------------------------------------------------------------- Comment By: Ahmet Bi?kinler (ahmetbiskinler) Date: 2006-08-21 09:55 Message: Logged In: YES user_id=1481281 There are still some problems with it. As in the image. http://img205.imageshack.us/img205/3998/turkishcharpythonyu5.jpg The upper() works fine(except ? and i uppercase) with IDLE since upper() doesn't even work. Another problem is with the ?(dotless) and i(dotted) 's upper. ?(dotless) should be I (dotless) i(dotted) should be ? (dotted) ? = I i = ? For more information: http://www.i18nguy.com/unicode/turkish-i18n.html ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-18 16:37 Message: Logged In: YES user_id=178886 Done: Bug #1542677 ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 21:08 Message: Logged In: YES user_id=849994 Please submit that as a separate IDLE bug. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 20:58 Message: Logged In: YES user_id=178886 Idle from 2.5rc1 (svn today) produces a different result than console (with my default, utf-8, encoding): IDLE 1.2c1 >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ?? >>> print len(u"?") 2 >>> print u"?".upper() ?? >>> str(u"?") Traceback (most recent call last): File "", line 1, in str(u"?") UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128) Again, IDLE 1.1.3 (python 2.4.3) produces a different result: IDLE 1.1.3 >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ?? >>> print len(u"?") 2 >>> print u"?".upper() ?? >>> str(u"?") '\xc3\x83\xc2\xa1' >>> I'd say idle is broken, as it is not able to respect utf-8 for print (or even len) of unicode strings. OTOH, with some tricks I can manage to get an accented a in a unicode in idle: >>> import unicodedata >>> print unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE") ? >>> print len(unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE")) 1 ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 17:08 Message: Logged In: YES user_id=849994 Using Unicode strings, the OP's example works. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-17 17:04 Message: Logged In: YES user_id=38388 String upper and lower conversion are locale dependent and implemented by the underlying libc, whereas Unicode upper/lower conversion is not and only depends on the Unicode character database. OTOH, there are special cases where the standard Unicode upper/lower mapping is no what you might expect, since the database only provides a single mapping and is not context aware. There's nothing we can do if the libc is broken in some respect. As for the extended case mapping support in Unicode: patches are welcome. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 17:03 Message: Logged In: YES user_id=849994 sgala: it looks like your console sends UTF-8 encoded text. >>> print "?" ? print is just printing out a byte string consisting of two bytes, which your console displays as accent-a. >>> print len("?") 2 A UTF-8-encoded string containing an accented a has two bytes. >>> print "?".upper() ? str.upper() doesn't take locale into account, so the accented a has no uppercase version defined. >>> str("?") '\xc3\xa1' str() applied to a byte string returns that byte string. Since return values from functions are printed by the interactive interpreter using repr() first, you get this representation (which you could also get from "print repr('a')".) >>> print u"?" ? That's also okay. Python knows the terminal encoding and properly translates the byte string to a unicode string of one character. On printout, it converts it to a UTF-8 string again, which your terminal displays correctly. >>> print len(u"?") 1 Since your two-byte-UTF-8 sequence is converted to a unicode character, the length of this unicode string is 1. >>> print u"?".upper() ? There are comprehensive capitalization tables available for unicode. >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) Applying str() to a unicode string must convert it to a byte string. If you don't specify an encoding, the default encoding is "ascii", which can't encode the accented a. Use "a".encode("utf-8"). ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 16:59 Message: Logged In: YES user_id=178886 (I tested it in 2.5rc1), 2.4 gives >>> str(u"?") '\xc3\xa1' instead of the exception ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 16:53 Message: Logged In: YES user_id=178886 The behaviour of python in this area is confusing. See a session with my Spanish keyboard: >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ? >>> print len(u"?") 1 >>> print u"?".upper() ? >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) I guess this is what is happening to the reporter. This violates the least surprising behavior principle in so many different ways that it hurts. Can anybody make sense of it? ---------------------------------------------------------------------- Comment By: Ahmet Bi?kinler (ahmetbiskinler) Date: 2006-08-11 10:10 Message: Logged In: YES user_id=1481281 What happened? Is it solved? How is it going? What is the final step? ...? ...? Could you please give me some information about the bug please? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 From noreply at sourceforge.net Mon Aug 21 14:08:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 05:08:35 -0700 Subject: [ python-Bugs-1543303 ] tarfile in mode w|gz adds padding that annoys gunzip Message-ID: Bugs item #1543303, was opened at 2006-08-20 03:48 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543303&group_id=5470 Please note that this 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: 8 Submitted By: alexis (asak) Assigned to: Neal Norwitz (nnorwitz) Summary: tarfile in mode w|gz adds padding that annoys gunzip Initial Comment: In mode w|gz tarfile pads the final block with NULs, until its size reaches the bufsize value passed to tarfile.open. This makes gunzip complain about "invalid compressed data" because of CRC and length errors. To reproduce it, put this fragment in a file archive.py import sys import tarfile tar = tarfile.open(mode='w|gz', fileobj=sys.stdout) tar.close() and then: $ python2.5 archive.py | gunzip -c gunzip: stdin: invalid compressed data--crc error gunzip: stdin: invalid compressed data--length error Everything works fine with python 2.3.5 and 2.4.1 on Debian sarge. The padding is added by the following lines in _Stream.close: blocks, remainder = divmod(len(self.buf), self.bufsize) if remainder > 0: self.buf += NUL * (self.bufsize - remainder) They were added in revision 38581, but I'm not sure why - at first sight, "Add tarfile open mode r|*" shouldn't have to change this write path. Removing them makes gunzip happy again, but I have no idea if it breaks something else (test_tarfile doesn't complain). A similar problem happens if you use mode w|bz2 and feed the output to bunzip - it complains about "trailing garbage after EOF ignored". Problems found while running the test suite from the Mercurial SCM. ---------------------------------------------------------------------- Comment By: Lars Gustäbel (gustaebel) Date: 2006-08-21 14:08 Message: Logged In: YES user_id=642936 I just created patch #1543897 that removes the 3 lines of code and adds a test to test_tarfile.py. Thank you for the detailed report. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-20 16:17 Message: Logged In: YES user_id=849994 This should be resolved before 2.5 final. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543303&group_id=5470 From noreply at sourceforge.net Mon Aug 21 19:59:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 10:59:36 -0700 Subject: [ python-Bugs-1544102 ] ctypes unit test fails (test_macholib.py) under MacOS 10.4.7 Message-ID: Bugs item #1544102, was opened at 2006-08-21 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=1544102&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Submitted By: M. J. Fromberger (njdibfm) Assigned to: Jack Jansen (jackjansen) Summary: ctypes unit test fails (test_macholib.py) under MacOS 10.4.7 Initial Comment: While building 2.5rc1 under MacOS 10.4.7, one of the ctypes module unit tests fails: % ./python.exe -V Python 2.5c1 (r25c1:51426, Aug 21 2006, 11:30:05) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin % uname -a Darwin chrysophylax 8.7.0 Darwin Kernel Version 8.7.0: Fri May 26 15:20:53 PDT 2006; root:xnu-792.6.76.obj~1/RELEASE_PPC Power Macintosh powerpc Output report: =========================================== =========================== FAIL: test_find (ctypes.test.test_macholib.MachOTest) ------------------------------------------------------------ ---------- Traceback (most recent call last): File "/usr/local/src/python2.5/Lib/ctypes/test/test_macholib.py", line 55, in test_find self.failUnless(result.startswith('/usr/lib/libz.1')) AssertionError ------------------------------------------------------------ ---------- Ran 287 tests in 0.933s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_ctypes.py", line 12, in test_main() File "Lib/test/test_ctypes.py", line 9, in test_main run_suite(unittest.TestSuite(suites)) File "/usr/local/src/python2.5/Lib/test/test_support.py", line 426, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/usr/local/src/python2.5/Lib/ctypes/test/test_macholib.py", line 55, in test_find self.failUnless(result.startswith('/usr/lib/libz.1')) AssertionError ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544102&group_id=5470 From noreply at sourceforge.net Mon Aug 21 20:02:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 11:02:48 -0700 Subject: [ python-Bugs-1544106 ] test_anydbm segmentation fault Message-ID: Bugs item #1544106, was opened at 2006-08-21 14:02 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Clay Spence (cspence) Assigned to: Nobody/Anonymous (nobody) Summary: test_anydbm segmentation fault Initial Comment: After building 2.5rc1 and bfore installing, make test failed for me at test_anydbm: cholla 88% uname -a Linux cholla.sarnoff.com 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53 EST 2006 i686 i686 i386 GNU/Linux cholla 89% ./python Python 2.5c1 (r25c1:51305, Aug 21 2006, 11:30:37) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> cholla 90% ./python ./Lib/test/test_anydbm.py Segmentation fault cholla 91% I tracked this to Lib/bsddb/__init__.py, line 355, in _openDBEnv(): e.set_lk_detect(db.DB_LOCK_DEFAULT) See the attached pdb text output, if it's useful. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&group_id=5470 From noreply at sourceforge.net Mon Aug 21 20:49:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 11:49:24 -0700 Subject: [ python-Bugs-1543303 ] tarfile in mode w|gz adds padding that annoys gunzip Message-ID: Bugs item #1543303, was opened at 2006-08-19 18:48 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543303&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: alexis (asak) Assigned to: Neal Norwitz (nnorwitz) Summary: tarfile in mode w|gz adds padding that annoys gunzip Initial Comment: In mode w|gz tarfile pads the final block with NULs, until its size reaches the bufsize value passed to tarfile.open. This makes gunzip complain about "invalid compressed data" because of CRC and length errors. To reproduce it, put this fragment in a file archive.py import sys import tarfile tar = tarfile.open(mode='w|gz', fileobj=sys.stdout) tar.close() and then: $ python2.5 archive.py | gunzip -c gunzip: stdin: invalid compressed data--crc error gunzip: stdin: invalid compressed data--length error Everything works fine with python 2.3.5 and 2.4.1 on Debian sarge. The padding is added by the following lines in _Stream.close: blocks, remainder = divmod(len(self.buf), self.bufsize) if remainder > 0: self.buf += NUL * (self.bufsize - remainder) They were added in revision 38581, but I'm not sure why - at first sight, "Add tarfile open mode r|*" shouldn't have to change this write path. Removing them makes gunzip happy again, but I have no idea if it breaks something else (test_tarfile doesn't complain). A similar problem happens if you use mode w|bz2 and feed the output to bunzip - it complains about "trailing garbage after EOF ignored". Problems found while running the test suite from the Mercurial SCM. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 11:49 Message: Logged In: YES user_id=33168 Committed revision 51432. (2.6) 51436 (2.5) ---------------------------------------------------------------------- Comment By: Lars Gustäbel (gustaebel) Date: 2006-08-21 05:08 Message: Logged In: YES user_id=642936 I just created patch #1543897 that removes the 3 lines of code and adds a test to test_tarfile.py. Thank you for the detailed report. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-20 07:17 Message: Logged In: YES user_id=849994 This should be resolved before 2.5 final. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543303&group_id=5470 From noreply at sourceforge.net Mon Aug 21 23:10:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 14:10:30 -0700 Subject: [ python-Bugs-1544102 ] ctypes unit test fails (test_macholib.py) under MacOS 10.4.7 Message-ID: Bugs item #1544102, was opened at 2006-08-21 19:59 Message generated for change (Settings changed) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544102&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 5 Submitted By: M. J. Fromberger (njdibfm) >Assigned to: Ronald Oussoren (ronaldoussoren) Summary: ctypes unit test fails (test_macholib.py) under MacOS 10.4.7 Initial Comment: While building 2.5rc1 under MacOS 10.4.7, one of the ctypes module unit tests fails: % ./python.exe -V Python 2.5c1 (r25c1:51426, Aug 21 2006, 11:30:05) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin % uname -a Darwin chrysophylax 8.7.0 Darwin Kernel Version 8.7.0: Fri May 26 15:20:53 PDT 2006; root:xnu-792.6.76.obj~1/RELEASE_PPC Power Macintosh powerpc Output report: =========================================== =========================== FAIL: test_find (ctypes.test.test_macholib.MachOTest) ------------------------------------------------------------ ---------- Traceback (most recent call last): File "/usr/local/src/python2.5/Lib/ctypes/test/test_macholib.py", line 55, in test_find self.failUnless(result.startswith('/usr/lib/libz.1')) AssertionError ------------------------------------------------------------ ---------- Ran 287 tests in 0.933s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_ctypes.py", line 12, in test_main() File "Lib/test/test_ctypes.py", line 9, in test_main run_suite(unittest.TestSuite(suites)) File "/usr/local/src/python2.5/Lib/test/test_support.py", line 426, in run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "/usr/local/src/python2.5/Lib/ctypes/test/test_macholib.py", line 55, in test_find self.failUnless(result.startswith('/usr/lib/libz.1')) AssertionError ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2006-08-21 23:10 Message: Logged In: YES user_id=45365 Ronald: just guesing that you know more about this than I do... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544102&group_id=5470 From noreply at sourceforge.net Tue Aug 22 01:15:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 16:15:59 -0700 Subject: [ python-Bugs-1544277 ] python compiler support for with stmt Message-ID: Bugs item #1544277, was opened at 2006-08-21 16:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544277&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Neil Schemenauer (nascheme) Summary: python compiler support for with stmt Initial Comment: With the attached patch, there are no crashes when running the test suite. Still 9 failures test_compile test_contextlib test_dis test_grammar test_inspect test_peepholer test_scope test_trace test_with There are at least 3 that seem to be real issues: test_compile test_contextlib test_with not sure if test_grammar or test_trace are a real problems or not. The attached patch is close but not perfect at fixing the with issue. The problem is that the STORE_FAST for the 'as' target is a LOAD_FAST (incorrectly). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544277&group_id=5470 From noreply at sourceforge.net Tue Aug 22 01:28:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 16:28:08 -0700 Subject: [ python-Bugs-1544106 ] test_anydbm segmentation fault Message-ID: Bugs item #1544106, was opened at 2006-08-21 11:02 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Clay Spence (cspence) Assigned to: Nobody/Anonymous (nobody) Summary: test_anydbm segmentation fault Initial Comment: After building 2.5rc1 and bfore installing, make test failed for me at test_anydbm: cholla 88% uname -a Linux cholla.sarnoff.com 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53 EST 2006 i686 i686 i386 GNU/Linux cholla 89% ./python Python 2.5c1 (r25c1:51305, Aug 21 2006, 11:30:37) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> cholla 90% ./python ./Lib/test/test_anydbm.py Segmentation fault cholla 91% I tracked this to Lib/bsddb/__init__.py, line 355, in _openDBEnv(): e.set_lk_detect(db.DB_LOCK_DEFAULT) See the attached pdb text output, if it's useful. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 16:28 Message: Logged In: YES user_id=33168 I'm guessing this is an old version of berkeley db. What version of bdb are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&group_id=5470 From noreply at sourceforge.net Tue Aug 22 01:43:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 16:43:20 -0700 Subject: [ python-Bugs-1467080 ] Many functions in socket module are not thread safe Message-ID: Bugs item #1467080, was opened at 2006-04-09 03:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Maxim Sobolev (sobomax) Assigned to: Nobody/Anonymous (nobody) Summary: Many functions in socket module are not thread safe Initial Comment: The socket module make a great effort to be thread-safe, but misses one big point - it uses single per-instance buffer to hold resolved sockaddr_xxx structures. Therefore, on SMP system it is possible that several threads calling functions that perform address resolution in parallel will stomp on each other resulting in incorrect or invalid address to be used in each case. For example, two threads calling sendto() in parallel can result in packets to be sent to incorrect addresses - packets from thread one from time to time will be sent to address requested by thread two and vice versa. Another, smaller issue is that the call to getnameinfo() is not protected with netdb mutex on systems that don't have thread-safe resolver. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-22 01:43 Message: Logged In: YES user_id=21627 The latest patch got resubmitted as #1544279. ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-25 00:31 Message: Logged In: YES user_id=24670 OK, it looks like the only way to get this bug fixed is to reimplement patch to use stack instead of heap, so that here we go. Attached please find new version of the patch which allocates address buffer on stack. -Maxim ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-18 01:05 Message: Logged In: YES user_id=24670 > The big win is in simplification of the code. What do you call "big simplification"? Several malloc/free calls and appropriate NULL checks? Aside from stack usage issues the big loss here is portability - we either need to use some fixed length buffer with the size sufficient to hold any type of address (ugly!) or use sockaddr_storage, which may not exist on all platforms supported by the python. -Maxim ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-18 00:51 Message: Logged In: YES user_id=21627 The big win is in simplification of the code. Also, we are not talking about 10k here. On Linux, sock_addr_t is 128 bytes. Take a look at set_error: it allocates 100 bytes for an error buffer. Or sock_repr: 512 bytes for a buffer. Or socket_gethostname: 1024 bytes. Or socket_gethostbyname_ex: 16384 bytes. socket_getaddrinfo: 30 bytes. os_init: 100 bytes Or, looking at other modules: symtable.c:check_unoptimized: 300 bytes. Py_GetVersion: 250 bytes. PySys_SetArgv: 2*MAXPATHLEN+1 (on Linux, this is 8193 bytes). I could go on. Don't worry about stack consumption. Or, if you do, analyse the Python source code, and fix the big offenders first. Premature optimization is the root of all evil. ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-18 00:10 Message: Logged In: YES user_id=24670 > The address space available to each thread typically doesn't > depend on the number of threads. Instead, the stack size is > pre-determined, so it's vice versa: the number of threads > supported depends on that stack-size, which (currently) isn't tunable. Yes, but my point is that on low-end and/or embedded system the system can be configured with as low stack per thread as possible (since with for example 100 threads, every extra 10K of stack per thread means 1M of extra memory, which in the absence of paging needs to be wired down) and if only one thread needs this stack 990K of it will be effectively wasted. And since getaddrinfo()-family already uses heap for its results I don't see any big win in avoiding extra malloc()/free() call. Expecially considering that we are dealing with i/o here, so that system call overhead will be much more than that anyway, even if the program calls those functions heavily. -Maxim ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-17 23:22 Message: Logged In: YES user_id=21627 The argument of "hundreds of threads" is a red herring. The address space available to each thread typically doesn't depend on the number of threads. Instead, the stack size is pre-determined, so it's vice versa: the number of threads supported depends on that stack-size, which (currently) isn't tunable. Also, stack space is typically a scarce resource only for recursive functions. For leave functions, it doesn't matter, unless a single function consumes the majority of the stack (which certainly wouldn't be the case here). Allocation on the stack is cheap, and over-allocation doesn't hurt. Please change the patch to use automatic variables. It will become simpler and more maintainable that way (in addition, it should also become minimally faster). ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-17 22:26 Message: Logged In: YES user_id=24670 > Why is it necessary to allocate the memory dynamically? > Couldn't the caller provide the memory on the stack (i.e. > through a local variable)? Local variable is not very good IMHO since in threading environment with hundreds of threads running at the same time stack can be a scarce resource. Another issue is that the caller doesn't know the actual size it has to allocate until the resolution has been done, therefore it would need to overallocate in most cases. -Maxim ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-11 07:22 Message: Logged In: YES user_id=21627 Why is it necessary to allocate the memory dynamically? Couldn't the caller provide the memory on the stack (i.e. through a local variable)? ---------------------------------------------------------------------- Comment By: Maxim Sobolev (sobomax) Date: 2006-04-11 02:08 Message: Logged In: YES user_id=24670 Sorry, for some reason the patch did not go through first time. See attached. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-04-09 23:18 Message: Logged In: YES user_id=21627 I wonder why the sock_addr member is there in the socket object in the first place. AFAICT, there is no need for it; it was introduced in r4509. Would you like to work on a patch? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1467080&group_id=5470 From noreply at sourceforge.net Tue Aug 22 02:12:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 17:12:59 -0700 Subject: [ python-Bugs-1544295 ] Fix Lib/test/test___all__.py Message-ID: Bugs item #1544295, was opened at 2006-08-21 17: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=1544295&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Demos and Tools Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Hasan Diwan (hdiwan650) Assigned to: Nobody/Anonymous (nobody) Summary: Fix Lib/test/test___all__.py Initial Comment: There's a comment saying: # In case _socket fails to build, make this test fail more gracefully # than an AttributeError somewhere deep in CGIHTTPServer. The proposed fix is attached. Applies to revision 51453. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544295&group_id=5470 From noreply at sourceforge.net Tue Aug 22 02:56:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 17:56:36 -0700 Subject: [ python-Bugs-1544306 ] checking size of int... configure: error: cannot compute siz Message-ID: Bugs item #1544306, was opened at 2006-08-21 20:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544306&group_id=5470 Please note that this 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: arrecostao (arrecostao) Assigned to: Nobody/Anonymous (nobody) Summary: checking size of int... configure: error: cannot compute siz Initial Comment: Getting multiple error messages when using ./configure # uname -a SunOS cromagnon 5.10 Generic i86pc i386 i86pc # ./configure checking MACHDEP... sunos5 checking EXTRAPLATDIR... checking for --without-gcc... no checking for --with-cxx=... no checking for c++... c++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for egrep... egrep checking for AIX... no checking for --with-suffix... checking for case-insensitive build directory... no checking LIBRARY... libpython$(VERSION).a checking LINKCC... $(PURIFY) $(CXX) checking for --enable-shared... no checking for --enable-profiling... checking LDLIBRARY... libpython$(VERSION).a checking for ranlib... ranlib checking for ar... ar checking for a BSD-compatible install... ./install-sh -c checking for --with-pydebug... no checking whether gcc accepts -fno-strict-aliasing... yes checking whether gcc accepts -OPT:Olimit=0... no checking whether gcc accepts -Olimit 1500... no checking whether pthreads are available without options... yes checking whether c++ also accepts flags for thread support... no checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... no checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking curses.h usability... yes checking curses.h presence... yes checking for curses.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking ncurses.h usability... no checking ncurses.h presence... no checking for ncurses.h... no checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking stropts.h usability... yes checking stropts.h presence... yes checking for stropts.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking thread.h usability... no checking thread.h presence... yes configure: WARNING: thread.h: present but cannot be compiled configure: WARNING: thread.h: check for missing prerequisite headers? configure: WARNING: thread.h: see the Autoconf documentation configure: WARNING: thread.h: section "Present But Cannot Be Compiled" configure: WARNING: thread.h: proceeding with the preprocessor's result configure: WARNING: thread.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 thread.h... yes checking for unistd.h... (cached) yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking sys/audioio.h usability... yes checking sys/audioio.h presence... yes checking for sys/audioio.h... yes checking sys/bsdtty.h usability... no checking sys/bsdtty.h presence... no checking for sys/bsdtty.h... no checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/loadavg.h usability... yes checking sys/loadavg.h presence... yes checking for sys/loadavg.h... yes checking sys/lock.h usability... yes checking sys/lock.h presence... yes checking for sys/lock.h... yes checking sys/mkdev.h usability... yes checking sys/mkdev.h presence... yes checking for sys/mkdev.h... yes checking sys/modem.h usability... no checking sys/modem.h presence... no checking for sys/modem.h... no checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking sys/poll.h usability... yes checking sys/poll.h presence... yes checking for sys/poll.h... yes checking sys/select.h usability... yes checking sys/select.h presence... yes checking for sys/select.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/times.h usability... yes checking sys/times.h presence... yes checking for sys/times.h... yes checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking sys/utsname.h usability... yes checking sys/utsname.h presence... yes checking for sys/utsname.h... yes checking sys/wait.h usability... no checking sys/wait.h presence... yes configure: WARNING: sys/wait.h: present but cannot be compiled configure: WARNING: sys/wait.h: check for missing prerequisite headers? configure: WARNING: sys/wait.h: see the Autoconf documentation configure: WARNING: sys/wait.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/wait.h: proceeding with the preprocessor's result configure: WARNING: sys/wait.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 sys/wait.h... yes checking pty.h usability... no checking pty.h presence... no checking for pty.h... no checking libutil.h usability... no checking libutil.h presence... no checking for libutil.h... no checking sys/resource.h usability... yes checking sys/resource.h presence... yes checking for sys/resource.h... yes checking netpacket/packet.h usability... no checking netpacket/packet.h presence... no checking for netpacket/packet.h... no checking sysexits.h usability... yes checking sysexits.h presence... yes checking for sysexits.h... yes checking bluetooth.h usability... no checking bluetooth.h presence... no checking for bluetooth.h... no checking bluetooth/bluetooth.h usability... no checking bluetooth/bluetooth.h presence... no checking for bluetooth/bluetooth.h... no checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking whether sys/types.h defines makedev... no checking for sys/mkdev.h... (cached) yes checking for term.h... yes checking for clock_t in time.h... yes checking for makedev... no checking Solaris LFS bug... no checking for mode_t... yes checking for off_t... yes checking for pid_t... yes checking return type of signal handlers... int checking for size_t... yes checking for uid_t in sys/types.h... yes checking for int... yes checking size of int... configure: error: cannot compute sizeof (int), 77 See `config.log' for more details. # ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544306&group_id=5470 From noreply at sourceforge.net Tue Aug 22 02:58:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 17:58:57 -0700 Subject: [ python-Bugs-1544306 ] checking size of int... configure: error: cannot compute siz Message-ID: Bugs item #1544306, was opened at 2006-08-21 20:56 Message generated for change (Comment added) made by arrecostao You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544306&group_id=5470 Please note that this 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: arrecostao (arrecostao) Assigned to: Nobody/Anonymous (nobody) Summary: checking size of int... configure: error: cannot compute siz Initial Comment: Getting multiple error messages when using ./configure # uname -a SunOS cromagnon 5.10 Generic i86pc i386 i86pc # ./configure checking MACHDEP... sunos5 checking EXTRAPLATDIR... checking for --without-gcc... no checking for --with-cxx=... no checking for c++... c++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for egrep... egrep checking for AIX... no checking for --with-suffix... checking for case-insensitive build directory... no checking LIBRARY... libpython$(VERSION).a checking LINKCC... $(PURIFY) $(CXX) checking for --enable-shared... no checking for --enable-profiling... checking LDLIBRARY... libpython$(VERSION).a checking for ranlib... ranlib checking for ar... ar checking for a BSD-compatible install... ./install-sh -c checking for --with-pydebug... no checking whether gcc accepts -fno-strict-aliasing... yes checking whether gcc accepts -OPT:Olimit=0... no checking whether gcc accepts -Olimit 1500... no checking whether pthreads are available without options... yes checking whether c++ also accepts flags for thread support... no checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... no checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking curses.h usability... yes checking curses.h presence... yes checking for curses.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking ncurses.h usability... no checking ncurses.h presence... no checking for ncurses.h... no checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking stropts.h usability... yes checking stropts.h presence... yes checking for stropts.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking thread.h usability... no checking thread.h presence... yes configure: WARNING: thread.h: present but cannot be compiled configure: WARNING: thread.h: check for missing prerequisite headers? configure: WARNING: thread.h: see the Autoconf documentation configure: WARNING: thread.h: section "Present But Cannot Be Compiled" configure: WARNING: thread.h: proceeding with the preprocessor's result configure: WARNING: thread.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 thread.h... yes checking for unistd.h... (cached) yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking sys/audioio.h usability... yes checking sys/audioio.h presence... yes checking for sys/audioio.h... yes checking sys/bsdtty.h usability... no checking sys/bsdtty.h presence... no checking for sys/bsdtty.h... no checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/loadavg.h usability... yes checking sys/loadavg.h presence... yes checking for sys/loadavg.h... yes checking sys/lock.h usability... yes checking sys/lock.h presence... yes checking for sys/lock.h... yes checking sys/mkdev.h usability... yes checking sys/mkdev.h presence... yes checking for sys/mkdev.h... yes checking sys/modem.h usability... no checking sys/modem.h presence... no checking for sys/modem.h... no checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking sys/poll.h usability... yes checking sys/poll.h presence... yes checking for sys/poll.h... yes checking sys/select.h usability... yes checking sys/select.h presence... yes checking for sys/select.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/times.h usability... yes checking sys/times.h presence... yes checking for sys/times.h... yes checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking sys/utsname.h usability... yes checking sys/utsname.h presence... yes checking for sys/utsname.h... yes checking sys/wait.h usability... no checking sys/wait.h presence... yes configure: WARNING: sys/wait.h: present but cannot be compiled configure: WARNING: sys/wait.h: check for missing prerequisite headers? configure: WARNING: sys/wait.h: see the Autoconf documentation configure: WARNING: sys/wait.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/wait.h: proceeding with the preprocessor's result configure: WARNING: sys/wait.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 sys/wait.h... yes checking pty.h usability... no checking pty.h presence... no checking for pty.h... no checking libutil.h usability... no checking libutil.h presence... no checking for libutil.h... no checking sys/resource.h usability... yes checking sys/resource.h presence... yes checking for sys/resource.h... yes checking netpacket/packet.h usability... no checking netpacket/packet.h presence... no checking for netpacket/packet.h... no checking sysexits.h usability... yes checking sysexits.h presence... yes checking for sysexits.h... yes checking bluetooth.h usability... no checking bluetooth.h presence... no checking for bluetooth.h... no checking bluetooth/bluetooth.h usability... no checking bluetooth/bluetooth.h presence... no checking for bluetooth/bluetooth.h... no checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking whether sys/types.h defines makedev... no checking for sys/mkdev.h... (cached) yes checking for term.h... yes checking for clock_t in time.h... yes checking for makedev... no checking Solaris LFS bug... no checking for mode_t... yes checking for off_t... yes checking for pid_t... yes checking return type of signal handlers... int checking for size_t... yes checking for uid_t in sys/types.h... yes checking for int... yes checking size of int... configure: error: cannot compute sizeof (int), 77 See `config.log' for more details. # ---------------------------------------------------------------------- >Comment By: arrecostao (arrecostao) Date: 2006-08-21 20:58 Message: Logged In: YES user_id=1523167 Does anyone know what I am missing? Any hints would be much appreciated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544306&group_id=5470 From noreply at sourceforge.net Tue Aug 22 06:28:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Aug 2006 21:28:13 -0700 Subject: [ python-Bugs-1544339 ] _ctypes fails to build on Solaris x86 32-bit (Sun compiler) Message-ID: Bugs item #1544339, was opened at 2006-08-21 21:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544339&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Case Van Horsen (casevh) Assigned to: Nobody/Anonymous (nobody) Summary: _ctypes fails to build on Solaris x86 32-bit (Sun compiler) Initial Comment: The _ctypes modules fails to compile on Solaris 10 x86 32-bit using the Sun Studio 11 compiler. _ctypes does compile successfully using gcc. The error messages are attached. If needed, I can provide access to the machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544339&group_id=5470 From noreply at sourceforge.net Tue Aug 22 09:15:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 00:15:10 -0700 Subject: [ python-Bugs-1544381 ] Bad result of calculation Message-ID: Bugs item #1544381, was opened at 2006-08-22 09:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544381&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Performance Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Jean-Christophe BERTOLINI (jbertoli) Assigned to: Nobody/Anonymous (nobody) Summary: Bad result of calculation Initial Comment: In the Python Shell enter: >>> 3.84-4.5 -0.66000000000000014 The last digits of the calculation result are wrong ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544381&group_id=5470 From noreply at sourceforge.net Tue Aug 22 10:20:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 01:20:01 -0700 Subject: [ python-Bugs-1544306 ] checking size of int... configure: error: cannot compute siz Message-ID: Bugs item #1544306, was opened at 2006-08-22 00:56 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544306&group_id=5470 Please note that this 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: arrecostao (arrecostao) Assigned to: Nobody/Anonymous (nobody) Summary: checking size of int... configure: error: cannot compute siz Initial Comment: Getting multiple error messages when using ./configure # uname -a SunOS cromagnon 5.10 Generic i86pc i386 i86pc # ./configure checking MACHDEP... sunos5 checking EXTRAPLATDIR... checking for --without-gcc... no checking for --with-cxx=... no checking for c++... c++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for egrep... egrep checking for AIX... no checking for --with-suffix... checking for case-insensitive build directory... no checking LIBRARY... libpython$(VERSION).a checking LINKCC... $(PURIFY) $(CXX) checking for --enable-shared... no checking for --enable-profiling... checking LDLIBRARY... libpython$(VERSION).a checking for ranlib... ranlib checking for ar... ar checking for a BSD-compatible install... ./install-sh -c checking for --with-pydebug... no checking whether gcc accepts -fno-strict-aliasing... yes checking whether gcc accepts -OPT:Olimit=0... no checking whether gcc accepts -Olimit 1500... no checking whether pthreads are available without options... yes checking whether c++ also accepts flags for thread support... no checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... no checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking curses.h usability... yes checking curses.h presence... yes checking for curses.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking fcntl.h usability... yes checking fcntl.h presence... yes checking for fcntl.h... yes checking grp.h usability... yes checking grp.h presence... yes checking for grp.h... yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking ncurses.h usability... no checking ncurses.h presence... no checking for ncurses.h... no checking poll.h usability... yes checking poll.h presence... yes checking for poll.h... yes checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking stropts.h usability... yes checking stropts.h presence... yes checking for stropts.h... yes checking termios.h usability... yes checking termios.h presence... yes checking for termios.h... yes checking thread.h usability... no checking thread.h presence... yes configure: WARNING: thread.h: present but cannot be compiled configure: WARNING: thread.h: check for missing prerequisite headers? configure: WARNING: thread.h: see the Autoconf documentation configure: WARNING: thread.h: section "Present But Cannot Be Compiled" configure: WARNING: thread.h: proceeding with the preprocessor's result configure: WARNING: thread.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 thread.h... yes checking for unistd.h... (cached) yes checking utime.h usability... yes checking utime.h presence... yes checking for utime.h... yes checking sys/audioio.h usability... yes checking sys/audioio.h presence... yes checking for sys/audioio.h... yes checking sys/bsdtty.h usability... no checking sys/bsdtty.h presence... no checking for sys/bsdtty.h... no checking sys/file.h usability... yes checking sys/file.h presence... yes checking for sys/file.h... yes checking sys/loadavg.h usability... yes checking sys/loadavg.h presence... yes checking for sys/loadavg.h... yes checking sys/lock.h usability... yes checking sys/lock.h presence... yes checking for sys/lock.h... yes checking sys/mkdev.h usability... yes checking sys/mkdev.h presence... yes checking for sys/mkdev.h... yes checking sys/modem.h usability... no checking sys/modem.h presence... no checking for sys/modem.h... no checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking sys/poll.h usability... yes checking sys/poll.h presence... yes checking for sys/poll.h... yes checking sys/select.h usability... yes checking sys/select.h presence... yes checking for sys/select.h... yes checking sys/socket.h usability... yes checking sys/socket.h presence... yes checking for sys/socket.h... yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/times.h usability... yes checking sys/times.h presence... yes checking for sys/times.h... yes checking sys/un.h usability... yes checking sys/un.h presence... yes checking for sys/un.h... yes checking sys/utsname.h usability... yes checking sys/utsname.h presence... yes checking for sys/utsname.h... yes checking sys/wait.h usability... no checking sys/wait.h presence... yes configure: WARNING: sys/wait.h: present but cannot be compiled configure: WARNING: sys/wait.h: check for missing prerequisite headers? configure: WARNING: sys/wait.h: see the Autoconf documentation configure: WARNING: sys/wait.h: section "Present But Cannot Be Compiled" configure: WARNING: sys/wait.h: proceeding with the preprocessor's result configure: WARNING: sys/wait.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 sys/wait.h... yes checking pty.h usability... no checking pty.h presence... no checking for pty.h... no checking libutil.h usability... no checking libutil.h presence... no checking for libutil.h... no checking sys/resource.h usability... yes checking sys/resource.h presence... yes checking for sys/resource.h... yes checking netpacket/packet.h usability... no checking netpacket/packet.h presence... no checking for netpacket/packet.h... no checking sysexits.h usability... yes checking sysexits.h presence... yes checking for sysexits.h... yes checking bluetooth.h usability... no checking bluetooth.h presence... no checking for bluetooth.h... no checking bluetooth/bluetooth.h usability... no checking bluetooth/bluetooth.h presence... no checking for bluetooth/bluetooth.h... no checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking whether sys/types.h defines makedev... no checking for sys/mkdev.h... (cached) yes checking for term.h... yes checking for clock_t in time.h... yes checking for makedev... no checking Solaris LFS bug... no checking for mode_t... yes checking for off_t... yes checking for pid_t... yes checking return type of signal handlers... int checking for size_t... yes checking for uid_t in sys/types.h... yes checking for int... yes checking size of int... configure: error: cannot compute sizeof (int), 77 See `config.log' for more details. # ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-22 08:20 Message: Logged In: YES user_id=849994 Please look into config.log to determine which input to the compiler didn't work, and post it here. ---------------------------------------------------------------------- Comment By: arrecostao (arrecostao) Date: 2006-08-22 00:58 Message: Logged In: YES user_id=1523167 Does anyone know what I am missing? Any hints would be much appreciated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544306&group_id=5470 From noreply at sourceforge.net Tue Aug 22 10:20:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 01:20:58 -0700 Subject: [ python-Bugs-1544381 ] Bad result of calculation Message-ID: Bugs item #1544381, was opened at 2006-08-22 07:15 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544381&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Performance Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jean-Christophe BERTOLINI (jbertoli) Assigned to: Nobody/Anonymous (nobody) Summary: Bad result of calculation Initial Comment: In the Python Shell enter: >>> 3.84-4.5 -0.66000000000000014 The last digits of the calculation result are wrong ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-22 08:20 Message: Logged In: YES user_id=849994 This is due to how floats work. See http://www.python.org/doc/faq/general/#why-are-floating-point-calculations-so-inaccurate . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544381&group_id=5470 From noreply at sourceforge.net Tue Aug 22 15:26:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 06:26:08 -0700 Subject: [ python-Bugs-1544106 ] test_anydbm segmentation fault Message-ID: Bugs item #1544106, was opened at 2006-08-21 14:02 Message generated for change (Comment added) made by cspence You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Clay Spence (cspence) Assigned to: Nobody/Anonymous (nobody) Summary: test_anydbm segmentation fault Initial Comment: After building 2.5rc1 and bfore installing, make test failed for me at test_anydbm: cholla 88% uname -a Linux cholla.sarnoff.com 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53 EST 2006 i686 i686 i386 GNU/Linux cholla 89% ./python Python 2.5c1 (r25c1:51305, Aug 21 2006, 11:30:37) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> cholla 90% ./python ./Lib/test/test_anydbm.py Segmentation fault cholla 91% I tracked this to Lib/bsddb/__init__.py, line 355, in _openDBEnv(): e.set_lk_detect(db.DB_LOCK_DEFAULT) See the attached pdb text output, if it's useful. ---------------------------------------------------------------------- >Comment By: Clay Spence (cspence) Date: 2006-08-22 09:26 Message: Logged In: YES user_id=685289 Excuse my ignorance, but I'm not sure how to determine the version. Poking around gives me: cholla 92% ./python Python 2.5c1 (r25c1:51305, Aug 21 2006, 11:30:37) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import bsddb >>> bsddb.__version__ '4.4.5' >>> bsddb._bsddb.version() (4, 2, 52) >>> Is it the second? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 19:28 Message: Logged In: YES user_id=33168 I'm guessing this is an old version of berkeley db. What version of bdb are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&group_id=5470 From noreply at sourceforge.net Tue Aug 22 15:45:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 06:45:30 -0700 Subject: [ python-Bugs-1544106 ] test_anydbm segmentation fault Message-ID: Bugs item #1544106, was opened at 2006-08-21 11:02 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Clay Spence (cspence) >Assigned to: Gregory P. Smith (greg) Summary: test_anydbm segmentation fault Initial Comment: After building 2.5rc1 and bfore installing, make test failed for me at test_anydbm: cholla 88% uname -a Linux cholla.sarnoff.com 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53 EST 2006 i686 i686 i386 GNU/Linux cholla 89% ./python Python 2.5c1 (r25c1:51305, Aug 21 2006, 11:30:37) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> cholla 90% ./python ./Lib/test/test_anydbm.py Segmentation fault cholla 91% I tracked this to Lib/bsddb/__init__.py, line 355, in _openDBEnv(): e.set_lk_detect(db.DB_LOCK_DEFAULT) See the attached pdb text output, if it's useful. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-22 06:45 Message: Logged In: YES user_id=33168 Yes, correct. 4.2.52 is the version of the C BSD DB library. That's a fairly old version. I believe the bug is in there. If you update to 4.3.x or 4.4.x, I suspect the problem will go away. I know very little about bsddb. The code looks quite simple. Assigning Greg as he's probably the only one that has a chance of knowing. ---------------------------------------------------------------------- Comment By: Clay Spence (cspence) Date: 2006-08-22 06:26 Message: Logged In: YES user_id=685289 Excuse my ignorance, but I'm not sure how to determine the version. Poking around gives me: cholla 92% ./python Python 2.5c1 (r25c1:51305, Aug 21 2006, 11:30:37) [GCC 3.4.5 20051201 (Red Hat 3.4.5-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import bsddb >>> bsddb.__version__ '4.4.5' >>> bsddb._bsddb.version() (4, 2, 52) >>> Is it the second? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 16:28 Message: Logged In: YES user_id=33168 I'm guessing this is an old version of berkeley db. What version of bdb are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544106&group_id=5470 From noreply at sourceforge.net Tue Aug 22 15:48:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 06:48:47 -0700 Subject: [ python-Bugs-1544339 ] _ctypes fails to build on Solaris x86 32-bit (Sun compiler) Message-ID: Bugs item #1544339, was opened at 2006-08-21 21:28 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544339&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Case Van Horsen (casevh) >Assigned to: Thomas Heller (theller) Summary: _ctypes fails to build on Solaris x86 32-bit (Sun compiler) Initial Comment: The _ctypes modules fails to compile on Solaris 10 x86 32-bit using the Sun Studio 11 compiler. _ctypes does compile successfully using gcc. The error messages are attached. If needed, I can provide access to the machine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544339&group_id=5470 From noreply at sourceforge.net Tue Aug 22 19:51:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 10:51:21 -0700 Subject: [ python-Bugs-1544762 ] x!=y and [x]==[y] (!) Message-ID: Bugs item #1544762, was opened at 2006-08-22 19:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: x!=y and [x]==[y] (!) Initial Comment: Easy to obtain the weird behavior in the summary (in 2.5rc1 and earlier): >>> inf=1e9999 >>> x = y = inf/inf >>> x!=y and [x]==[y] True I propose to fix it by ensuring that lists (and tuples etc) compare their items with exactly the same logic as the == and != operators use. Alex (aleaxit at gmail.com) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 From noreply at sourceforge.net Tue Aug 22 22:47:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 13:47:27 -0700 Subject: [ python-Bugs-1542308 ] Nested finally in generators don't follow PEP 342 Message-ID: Bugs item #1542308, was opened at 2006-08-17 18:56 Message generated for change (Comment added) made by gvanrossum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Nested finally in generators don't follow PEP 342 Initial Comment: The close() and GC interaction of generators that use yield inside of finally blocks doesn't execute correctly when nested. See the attached example. More information about the issue is in the Mozilla bug tracker (they found a similar bug in their implementation for JS 1.7): https://bugzilla.mozilla.org/show_bug.cgi?id=349012 ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-22 16:47 Message: Logged In: YES user_id=6380 I lost my patience halfway through reading the Mozilla bug tracker, but IMO this works as designed. The philosophical question is, would you rather see the outer finally clause reached in your example, or would you rather see the following generator terminated upon close? (If you "fix" the former, the latter ends up in an infinite loop when you attempt to close() or GC it.) def gen(): while True: try: yield except: pass ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&group_id=5470 From noreply at sourceforge.net Tue Aug 22 23:00:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 14:00:25 -0700 Subject: [ python-Bugs-1542308 ] Nested finally in generators don't follow PEP 342 Message-ID: Bugs item #1542308, was opened at 2006-08-17 18:56 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Nested finally in generators don't follow PEP 342 Initial Comment: The close() and GC interaction of generators that use yield inside of finally blocks doesn't execute correctly when nested. See the attached example. More information about the issue is in the Mozilla bug tracker (they found a similar bug in their implementation for JS 1.7): https://bugzilla.mozilla.org/show_bug.cgi?id=349012 ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2006-08-22 17:00 Message: Logged In: YES user_id=139309 Uh no, that wouldn't reach an infinite loop because any attempt to yield during close will raise RuntimeError and terminate the loop. The problem is that finally doesn't execute. Finally clauses always must execute. If they don't, then they're worthless. The real strange issue is that if close is called, then GC makes a second attempt, and it *does* execute the outer finally clause. There are definitely bugs here. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-22 16:47 Message: Logged In: YES user_id=6380 I lost my patience halfway through reading the Mozilla bug tracker, but IMO this works as designed. The philosophical question is, would you rather see the outer finally clause reached in your example, or would you rather see the following generator terminated upon close? (If you "fix" the former, the latter ends up in an infinite loop when you attempt to close() or GC it.) def gen(): while True: try: yield except: pass ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&group_id=5470 From noreply at sourceforge.net Wed Aug 23 00:23:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 15:23:27 -0700 Subject: [ python-Bugs-1542308 ] Nested finally in generators don't follow PEP 342 Message-ID: Bugs item #1542308, was opened at 2006-08-17 22:56 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Nested finally in generators don't follow PEP 342 Initial Comment: The close() and GC interaction of generators that use yield inside of finally blocks doesn't execute correctly when nested. See the attached example. More information about the issue is in the Mozilla bug tracker (they found a similar bug in their implementation for JS 1.7): https://bugzilla.mozilla.org/show_bug.cgi?id=349012 ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2006-08-22 22:23 Message: Logged In: YES user_id=56214 Bob, the problem Guido is pointing out is that to run the finally clauses, we have to resume the generator with the RuntimeError thus generated. So it doesn't terminate the loop, because the RuntimeError is effectively raised at the point where the yield occurs. So, in order to run finally clauses sanely after a close() attempt, we would have to prevent such loops. That doesn't mean Guido's example is valid as such; but I think it's possible to accidentally create quasi-indefinite loops using infinite iterators written prior to Python 2.5, if you had a try/except block that was expecting to catch something *other* than GeneratorExit or RuntimeError. So, the net effect would be an unintended hang, if we tried to support retrying until the generator can be closed. Regarding the GC second attempt, this behavior is actually exactly as-specified by the PEP's pseudo-code explanation of how close() is handled. A RuntimeError raised from close() does *not* close the generator; it specifically indicates that the generator has not in fact closed. At this point, after re-reading the PEP and looking at what the code is doing, it's clear that the behavior is "as specified", so the title of the bug is incorrect: the behavior is exactly as specified by PEP 342. So, the rest of my comments below are regarding whether PEP 342 should be changed. And really, the question there is whether it's sane to attempt heroic measures in order to run finally clauses in a generator whose code is *known* to be buggy. The RuntimeError basically says, "this generator is broken", and the GC also tries a second time to close it. If two close attempts don't close it, it's a dead duck. What other measures can we sanely add? We could try forcing the RuntimeError into the generator itself, but then we have to deal with the infinite loop possibility, and the oddities involved in getting to a language specification that can be implemented for Jython, IronPython, etc. On the whole, I think that we probably reached the right balance the first time around: a broken generator should not be allowed to handle the error of its own brokenness. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-08-22 21:00 Message: Logged In: YES user_id=139309 Uh no, that wouldn't reach an infinite loop because any attempt to yield during close will raise RuntimeError and terminate the loop. The problem is that finally doesn't execute. Finally clauses always must execute. If they don't, then they're worthless. The real strange issue is that if close is called, then GC makes a second attempt, and it *does* execute the outer finally clause. There are definitely bugs here. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-22 20:47 Message: Logged In: YES user_id=6380 I lost my patience halfway through reading the Mozilla bug tracker, but IMO this works as designed. The philosophical question is, would you rather see the outer finally clause reached in your example, or would you rather see the following generator terminated upon close? (If you "fix" the former, the latter ends up in an infinite loop when you attempt to close() or GC it.) def gen(): while True: try: yield except: pass ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&group_id=5470 From noreply at sourceforge.net Wed Aug 23 00:30:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 15:30:21 -0700 Subject: [ python-Bugs-1542308 ] Nested finally in generators don't follow PEP 342 Message-ID: Bugs item #1542308, was opened at 2006-08-17 18:56 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Nested finally in generators don't follow PEP 342 Initial Comment: The close() and GC interaction of generators that use yield inside of finally blocks doesn't execute correctly when nested. See the attached example. More information about the issue is in the Mozilla bug tracker (they found a similar bug in their implementation for JS 1.7): https://bugzilla.mozilla.org/show_bug.cgi?id=349012 ---------------------------------------------------------------------- >Comment By: Bob Ippolito (etrepum) Date: 2006-08-22 18:30 Message: Logged In: YES user_id=139309 It seems that the infinite loop would be the right thing to do, given that's what would happen in a similarly broken __del__ (or anywhere else). ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2006-08-22 18:23 Message: Logged In: YES user_id=56214 Bob, the problem Guido is pointing out is that to run the finally clauses, we have to resume the generator with the RuntimeError thus generated. So it doesn't terminate the loop, because the RuntimeError is effectively raised at the point where the yield occurs. So, in order to run finally clauses sanely after a close() attempt, we would have to prevent such loops. That doesn't mean Guido's example is valid as such; but I think it's possible to accidentally create quasi-indefinite loops using infinite iterators written prior to Python 2.5, if you had a try/except block that was expecting to catch something *other* than GeneratorExit or RuntimeError. So, the net effect would be an unintended hang, if we tried to support retrying until the generator can be closed. Regarding the GC second attempt, this behavior is actually exactly as-specified by the PEP's pseudo-code explanation of how close() is handled. A RuntimeError raised from close() does *not* close the generator; it specifically indicates that the generator has not in fact closed. At this point, after re-reading the PEP and looking at what the code is doing, it's clear that the behavior is "as specified", so the title of the bug is incorrect: the behavior is exactly as specified by PEP 342. So, the rest of my comments below are regarding whether PEP 342 should be changed. And really, the question there is whether it's sane to attempt heroic measures in order to run finally clauses in a generator whose code is *known* to be buggy. The RuntimeError basically says, "this generator is broken", and the GC also tries a second time to close it. If two close attempts don't close it, it's a dead duck. What other measures can we sanely add? We could try forcing the RuntimeError into the generator itself, but then we have to deal with the infinite loop possibility, and the oddities involved in getting to a language specification that can be implemented for Jython, IronPython, etc. On the whole, I think that we probably reached the right balance the first time around: a broken generator should not be allowed to handle the error of its own brokenness. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-08-22 17:00 Message: Logged In: YES user_id=139309 Uh no, that wouldn't reach an infinite loop because any attempt to yield during close will raise RuntimeError and terminate the loop. The problem is that finally doesn't execute. Finally clauses always must execute. If they don't, then they're worthless. The real strange issue is that if close is called, then GC makes a second attempt, and it *does* execute the outer finally clause. There are definitely bugs here. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-22 16:47 Message: Logged In: YES user_id=6380 I lost my patience halfway through reading the Mozilla bug tracker, but IMO this works as designed. The philosophical question is, would you rather see the outer finally clause reached in your example, or would you rather see the following generator terminated upon close? (If you "fix" the former, the latter ends up in an infinite loop when you attempt to close() or GC it.) def gen(): while True: try: yield except: pass ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&group_id=5470 From noreply at sourceforge.net Wed Aug 23 00:49:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 15:49:04 -0700 Subject: [ python-Bugs-1544762 ] x!=y and [x]==[y] (!) Message-ID: Bugs item #1544762, was opened at 2006-08-22 17:51 Message generated for change (Comment added) made by charlesmerriam You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: x!=y and [x]==[y] (!) Initial Comment: Easy to obtain the weird behavior in the summary (in 2.5rc1 and earlier): >>> inf=1e9999 >>> x = y = inf/inf >>> x!=y and [x]==[y] True I propose to fix it by ensuring that lists (and tuples etc) compare their items with exactly the same logic as the == and != operators use. Alex (aleaxit at gmail.com) ---------------------------------------------------------------------- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-22 22:49 Message: Logged In: YES user_id=1581732 This appears to be a special oddity of NaN, which is a member of the set of "Things That Do Not Equal Themselves". 1. Are there any more members of this set? 2. Does this mean that any complex data type containing an integer is no a member of this set? 3. Is it odd that, say, a user's StatisticsArray will not equal itself if some statistic in the array is Nan? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 From noreply at sourceforge.net Wed Aug 23 00:51:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 15:51:59 -0700 Subject: [ python-Bugs-1542308 ] Nested finally in generators don't follow PEP 342 Message-ID: Bugs item #1542308, was opened at 2006-08-17 22:56 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 8 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Nested finally in generators don't follow PEP 342 Initial Comment: The close() and GC interaction of generators that use yield inside of finally blocks doesn't execute correctly when nested. See the attached example. More information about the issue is in the Mozilla bug tracker (they found a similar bug in their implementation for JS 1.7): https://bugzilla.mozilla.org/show_bug.cgi?id=349012 ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2006-08-22 22:51 Message: Logged In: YES user_id=56214 You'll need to propose a patch to PEP 342 to alter the specification, then, and get it past Python-Dev. Personally, I don't think that changing the spec is the right thing to do for 2.5. But irrespective of those procedural matters, your __del__ analogy is flawed on two points. First, we do not re-run a __del__ method to handle an error that was raised by that __del__ method! Second, if a generator contains an infinite, non-yielding loop, then of course it will loop forever. So __del__ does not provide any actually useful guidance here. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-08-22 22:30 Message: Logged In: YES user_id=139309 It seems that the infinite loop would be the right thing to do, given that's what would happen in a similarly broken __del__ (or anywhere else). ---------------------------------------------------------------------- Comment By: Phillip J. Eby (pje) Date: 2006-08-22 22:23 Message: Logged In: YES user_id=56214 Bob, the problem Guido is pointing out is that to run the finally clauses, we have to resume the generator with the RuntimeError thus generated. So it doesn't terminate the loop, because the RuntimeError is effectively raised at the point where the yield occurs. So, in order to run finally clauses sanely after a close() attempt, we would have to prevent such loops. That doesn't mean Guido's example is valid as such; but I think it's possible to accidentally create quasi-indefinite loops using infinite iterators written prior to Python 2.5, if you had a try/except block that was expecting to catch something *other* than GeneratorExit or RuntimeError. So, the net effect would be an unintended hang, if we tried to support retrying until the generator can be closed. Regarding the GC second attempt, this behavior is actually exactly as-specified by the PEP's pseudo-code explanation of how close() is handled. A RuntimeError raised from close() does *not* close the generator; it specifically indicates that the generator has not in fact closed. At this point, after re-reading the PEP and looking at what the code is doing, it's clear that the behavior is "as specified", so the title of the bug is incorrect: the behavior is exactly as specified by PEP 342. So, the rest of my comments below are regarding whether PEP 342 should be changed. And really, the question there is whether it's sane to attempt heroic measures in order to run finally clauses in a generator whose code is *known* to be buggy. The RuntimeError basically says, "this generator is broken", and the GC also tries a second time to close it. If two close attempts don't close it, it's a dead duck. What other measures can we sanely add? We could try forcing the RuntimeError into the generator itself, but then we have to deal with the infinite loop possibility, and the oddities involved in getting to a language specification that can be implemented for Jython, IronPython, etc. On the whole, I think that we probably reached the right balance the first time around: a broken generator should not be allowed to handle the error of its own brokenness. ---------------------------------------------------------------------- Comment By: Bob Ippolito (etrepum) Date: 2006-08-22 21:00 Message: Logged In: YES user_id=139309 Uh no, that wouldn't reach an infinite loop because any attempt to yield during close will raise RuntimeError and terminate the loop. The problem is that finally doesn't execute. Finally clauses always must execute. If they don't, then they're worthless. The real strange issue is that if close is called, then GC makes a second attempt, and it *does* execute the outer finally clause. There are definitely bugs here. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-08-22 20:47 Message: Logged In: YES user_id=6380 I lost my patience halfway through reading the Mozilla bug tracker, but IMO this works as designed. The philosophical question is, would you rather see the outer finally clause reached in your example, or would you rather see the following generator terminated upon close? (If you "fix" the former, the latter ends up in an infinite loop when you attempt to close() or GC it.) def gen(): while True: try: yield except: pass ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542308&group_id=5470 From noreply at sourceforge.net Wed Aug 23 01:50:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 16:50:44 -0700 Subject: [ python-Bugs-1495488 ] make altinstall installs pydoc Message-ID: Bugs item #1495488, was opened at 2006-05-26 12:19 Message generated for change (Comment added) made by charlesmerriam You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Heaney (theaney) Assigned to: Nobody/Anonymous (nobody) Summary: make altinstall installs pydoc Initial Comment: I did the "make altinstall" rather than the "make install" as suggested on http://www.python.org/download/releases/2.5/ This worked great, creating a /usr/local/bin/python2.5 which doesn't clash with my /usr/bin/python. However, it also created a /usr/local/bin/pydoc which did clash with my /usr/bin/pydoc. I just removed it and all is well. Should altinstall not create pydoc? It could create pydoc2.5 rather than pydoc, but then the shebang line would have to be changed to python2.5. What about smtpd.py, idle, and python-config, which were also created by altinstall? They don't currently conflict with anything I have for Python 2.4, but the potential is there for the same problem. ---------------------------------------------------------------------- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-22 23:50 Message: Logged In: YES user_id=1581732 Ah, it's a bit worse than that. Your /usr/loca/bin/pydoc would not have worked anyway. It's first line: #!/usr/local/bin/python would give an error because only /usr/local/bin/python2.5 exists. ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2006-06-22 00:14 Message: Logged In: YES user_id=827666 Sorry, I haven't had a chance to look at this again. I just installed Python-2.5b1 and it's still the same way. Here's what I did to fix things up after the make altinstall... # cd /usr/local/bin # for file in pydoc idle smtpd.py python-config; do mv $file ${file}2.5 sed -i 's@/usr/local/bin/python@/usr/local/bin/python2.5@' ${file}2.5 done Now, how to fix up the Makefile.pre and setup.py so this isn't necessary... ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2006-06-06 11:19 Message: Logged In: YES user_id=827666 I'm not sure I know how. It looks like the downloaded files have the following shebang lines Tools/scripts/pydoc => #!/usr/bin/env python Tools/scripts/idle => #! /usr/bin/env python Lib/smtpd.py => #! /usr/bin/env python Misc/python-config.in => #!@BINDIR@/python whereas the installed files have /usr/local/bin/pydoc => #!/usr/local/bin/python /usr/local/bin/idle => #!/usr/local/bin/python /usr/local/bin/smtpd.py => #!/usr/local/bin/python /usr/local/bin/python-config => #!/usr/local/bin/python so they're already getting rewritten somewhere. We want both their names and their shebang lines to have the version /usr/local/bin/pydoc2.5 => #!/usr/local/bin/python2.5 /usr/local/bin/idle2.5 => #!/usr/local/bin/python2.5 /usr/local/bin/smtpd.py2.5 => #!/usr/local/bin/python2.5 /usr/local/bin/python-config2.5 => #!/usr/local/bin/python2.5 It seems that python-config appears in the Makefile, so adding something like sed -e "s, at BINDIR@,$(BINDIR)," < $(srcdir)/Misc/python-config.in >python-config$(VERSION)$(EXE) $(INSTALL_SCRIPT) python-config $(BINDIR)/python-config$(VERSION)$(EXE) rm python-config to Makefile.pre.in in an altlibainstall section or something might be all we need for that. The others are named in setup.py # Scripts to install scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', 'Lib/smtpd.py'] but I haven't worked out where they get rewritten or installed yet. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-04 20:02 Message: Logged In: YES user_id=21627 You are right: altinstall shouldn't overwrite these conflicting files. For idle and pydoc, I would think that altinstall should install version-specific copies - users actually might want to run an idle or pydoc associated with a specific version, likewise for python-config. I'm uncertain why smtpd.py is installed at all. Would you be willing to work on a patch? You are right that the shebang line should get updated during the installation, too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&group_id=5470 From noreply at sourceforge.net Wed Aug 23 02:39:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 17:39:49 -0700 Subject: [ python-Bugs-1495488 ] make altinstall installs pydoc Message-ID: Bugs item #1495488, was opened at 2006-05-26 12:19 Message generated for change (Comment added) made by theaney You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Heaney (theaney) Assigned to: Nobody/Anonymous (nobody) Summary: make altinstall installs pydoc Initial Comment: I did the "make altinstall" rather than the "make install" as suggested on http://www.python.org/download/releases/2.5/ This worked great, creating a /usr/local/bin/python2.5 which doesn't clash with my /usr/bin/python. However, it also created a /usr/local/bin/pydoc which did clash with my /usr/bin/pydoc. I just removed it and all is well. Should altinstall not create pydoc? It could create pydoc2.5 rather than pydoc, but then the shebang line would have to be changed to python2.5. What about smtpd.py, idle, and python-config, which were also created by altinstall? They don't currently conflict with anything I have for Python 2.4, but the potential is there for the same problem. ---------------------------------------------------------------------- >Comment By: Tim Heaney (theaney) Date: 2006-08-23 00:39 Message: Logged In: YES user_id=827666 Yeah, that's what the sed command is for. By the way, it looks like python-config is taken care of in release candidate 1. That is, after doing the altinstall for 2.5c1, I did # for file in pydoc idle smtpd.py; do mv $file ${file}2.5 sed -i 's@/usr/local/bin/python@/usr/local/bin/python2.5@' ${file}2.5 done to fix things up. ---------------------------------------------------------------------- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-22 23:50 Message: Logged In: YES user_id=1581732 Ah, it's a bit worse than that. Your /usr/loca/bin/pydoc would not have worked anyway. It's first line: #!/usr/local/bin/python would give an error because only /usr/local/bin/python2.5 exists. ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2006-06-22 00:14 Message: Logged In: YES user_id=827666 Sorry, I haven't had a chance to look at this again. I just installed Python-2.5b1 and it's still the same way. Here's what I did to fix things up after the make altinstall... # cd /usr/local/bin # for file in pydoc idle smtpd.py python-config; do mv $file ${file}2.5 sed -i 's@/usr/local/bin/python@/usr/local/bin/python2.5@' ${file}2.5 done Now, how to fix up the Makefile.pre and setup.py so this isn't necessary... ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2006-06-06 11:19 Message: Logged In: YES user_id=827666 I'm not sure I know how. It looks like the downloaded files have the following shebang lines Tools/scripts/pydoc => #!/usr/bin/env python Tools/scripts/idle => #! /usr/bin/env python Lib/smtpd.py => #! /usr/bin/env python Misc/python-config.in => #!@BINDIR@/python whereas the installed files have /usr/local/bin/pydoc => #!/usr/local/bin/python /usr/local/bin/idle => #!/usr/local/bin/python /usr/local/bin/smtpd.py => #!/usr/local/bin/python /usr/local/bin/python-config => #!/usr/local/bin/python so they're already getting rewritten somewhere. We want both their names and their shebang lines to have the version /usr/local/bin/pydoc2.5 => #!/usr/local/bin/python2.5 /usr/local/bin/idle2.5 => #!/usr/local/bin/python2.5 /usr/local/bin/smtpd.py2.5 => #!/usr/local/bin/python2.5 /usr/local/bin/python-config2.5 => #!/usr/local/bin/python2.5 It seems that python-config appears in the Makefile, so adding something like sed -e "s, at BINDIR@,$(BINDIR)," < $(srcdir)/Misc/python-config.in >python-config$(VERSION)$(EXE) $(INSTALL_SCRIPT) python-config $(BINDIR)/python-config$(VERSION)$(EXE) rm python-config to Makefile.pre.in in an altlibainstall section or something might be all we need for that. The others are named in setup.py # Scripts to install scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', 'Lib/smtpd.py'] but I haven't worked out where they get rewritten or installed yet. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-04 20:02 Message: Logged In: YES user_id=21627 You are right: altinstall shouldn't overwrite these conflicting files. For idle and pydoc, I would think that altinstall should install version-specific copies - users actually might want to run an idle or pydoc associated with a specific version, likewise for python-config. I'm uncertain why smtpd.py is installed at all. Would you be willing to work on a patch? You are right that the shebang line should get updated during the installation, too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&group_id=5470 From noreply at sourceforge.net Wed Aug 23 03:36:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Aug 2006 18:36:43 -0700 Subject: [ python-Bugs-1531963 ] SocketServer.TCPServer returns different ports Message-ID: Bugs item #1531963, was opened at 2006-07-31 19:58 Message generated for change (Comment added) made by damonkohler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531963&group_id=5470 Please note that this 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: hakker.de (hakker_de) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer.TCPServer returns different ports Initial Comment: Providing 0 as a port in __init__ of SocketServer.TCPServer leads to different values for port in server_address and socket.getsockname(). Example: import SocketServer s = SocketServer.TCPServer(("0.0.0.0", 0), Handler) s.server_address -> ('0.0.0.0', 0) s.socket.getsockname() -> ('0.0.0.0', 39129) s.server_address should also contain 39129 as the port number for the free port found. ---------------------------------------------------------------------- Comment By: Damon Kohler (damonkohler) Date: 2006-08-23 01:36 Message: Logged In: YES user_id=705317 Patch 1545011 is a proposed fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531963&group_id=5470 From noreply at sourceforge.net Wed Aug 23 10:12:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 01:12:38 -0700 Subject: [ python-Bugs-1495488 ] make altinstall installs pydoc Message-ID: Bugs item #1495488, was opened at 2006-05-26 12:19 Message generated for change (Comment added) made by charlesmerriam You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Heaney (theaney) Assigned to: Nobody/Anonymous (nobody) Summary: make altinstall installs pydoc Initial Comment: I did the "make altinstall" rather than the "make install" as suggested on http://www.python.org/download/releases/2.5/ This worked great, creating a /usr/local/bin/python2.5 which doesn't clash with my /usr/bin/python. However, it also created a /usr/local/bin/pydoc which did clash with my /usr/bin/pydoc. I just removed it and all is well. Should altinstall not create pydoc? It could create pydoc2.5 rather than pydoc, but then the shebang line would have to be changed to python2.5. What about smtpd.py, idle, and python-config, which were also created by altinstall? They don't currently conflict with anything I have for Python 2.4, but the potential is there for the same problem. ---------------------------------------------------------------------- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-23 08:12 Message: Logged In: YES user_id=1581732 A bit more background; I'm starting to appreciate the problem. The makefile plays a part, but the real problem is down is down in Lib/distutils/command/install_scripts.py. Makefile/altinstall builds Makefile/sharedinstall executes setup.py imports distutils.core/setup() invokes indirectly distuitls.commands/install_scripts.py And install_scripts.py needs to be taught about the suffixes, or be passed a new destination filename. Note that setup() must be backward compatible back several versions. So it seems like the problems are: 1. Change the Makefile target sharedinstall to somehow pass the right suffix into setup. Also make sharedinstall alter the scripts to call the right version of python. 2. Change the Makefile target bininstall to add hard links for the scripts, e.g., from pydoc2.5 to pydoc. 3. Somehow pick up the parameters in Lib/distutils/commands/install_scripts.py and tack on the right suffix when copying. I'll whack at it tomorrow. ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2006-08-23 00:39 Message: Logged In: YES user_id=827666 Yeah, that's what the sed command is for. By the way, it looks like python-config is taken care of in release candidate 1. That is, after doing the altinstall for 2.5c1, I did # for file in pydoc idle smtpd.py; do mv $file ${file}2.5 sed -i 's@/usr/local/bin/python@/usr/local/bin/python2.5@' ${file}2.5 done to fix things up. ---------------------------------------------------------------------- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-22 23:50 Message: Logged In: YES user_id=1581732 Ah, it's a bit worse than that. Your /usr/loca/bin/pydoc would not have worked anyway. It's first line: #!/usr/local/bin/python would give an error because only /usr/local/bin/python2.5 exists. ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2006-06-22 00:14 Message: Logged In: YES user_id=827666 Sorry, I haven't had a chance to look at this again. I just installed Python-2.5b1 and it's still the same way. Here's what I did to fix things up after the make altinstall... # cd /usr/local/bin # for file in pydoc idle smtpd.py python-config; do mv $file ${file}2.5 sed -i 's@/usr/local/bin/python@/usr/local/bin/python2.5@' ${file}2.5 done Now, how to fix up the Makefile.pre and setup.py so this isn't necessary... ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2006-06-06 11:19 Message: Logged In: YES user_id=827666 I'm not sure I know how. It looks like the downloaded files have the following shebang lines Tools/scripts/pydoc => #!/usr/bin/env python Tools/scripts/idle => #! /usr/bin/env python Lib/smtpd.py => #! /usr/bin/env python Misc/python-config.in => #!@BINDIR@/python whereas the installed files have /usr/local/bin/pydoc => #!/usr/local/bin/python /usr/local/bin/idle => #!/usr/local/bin/python /usr/local/bin/smtpd.py => #!/usr/local/bin/python /usr/local/bin/python-config => #!/usr/local/bin/python so they're already getting rewritten somewhere. We want both their names and their shebang lines to have the version /usr/local/bin/pydoc2.5 => #!/usr/local/bin/python2.5 /usr/local/bin/idle2.5 => #!/usr/local/bin/python2.5 /usr/local/bin/smtpd.py2.5 => #!/usr/local/bin/python2.5 /usr/local/bin/python-config2.5 => #!/usr/local/bin/python2.5 It seems that python-config appears in the Makefile, so adding something like sed -e "s, at BINDIR@,$(BINDIR)," < $(srcdir)/Misc/python-config.in >python-config$(VERSION)$(EXE) $(INSTALL_SCRIPT) python-config $(BINDIR)/python-config$(VERSION)$(EXE) rm python-config to Makefile.pre.in in an altlibainstall section or something might be all we need for that. The others are named in setup.py # Scripts to install scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', 'Lib/smtpd.py'] but I haven't worked out where they get rewritten or installed yet. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-04 20:02 Message: Logged In: YES user_id=21627 You are right: altinstall shouldn't overwrite these conflicting files. For idle and pydoc, I would think that altinstall should install version-specific copies - users actually might want to run an idle or pydoc associated with a specific version, likewise for python-config. I'm uncertain why smtpd.py is installed at all. Would you be willing to work on a patch? You are right that the shebang line should get updated during the installation, too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&group_id=5470 From noreply at sourceforge.net Wed Aug 23 10:43:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 01:43:38 -0700 Subject: [ python-Bugs-1514428 ] NaN comparison in Decimal broken Message-ID: Bugs item #1514428, was opened at 2006-06-29 16:19 Message generated for change (Comment added) made by charlesmerriam You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514428&group_id=5470 Please note that this 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: Nick Maclaren (nmm) Assigned to: Raymond Hettinger (rhettinger) Summary: NaN comparison in Decimal broken Initial Comment: Methinks this is a bit off :-) True should be False. Python 2.5b1 (trunk:47059, Jun 29 2006, 14:26:46) [GCC 4.1.0 (SUSE Linux)] on linux2 >>> import decimal >>> d = decimal.Decimal >>> inf = d("inf") >>> nan = d("nan") >>> nan > inf True >>> nan < inf False >>> inf > nan True >>> inf < nan False b ---------------------------------------------------------------------- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-23 08:43 Message: Logged In: YES user_id=1581732 More specifically, any comparison with a NaN should equal False, even inf, per IEEE 754. A good starting point to convince oneself of this is http://en.wikipedia.org/wiki/NaN. ---------------------------------------------------------------------- Comment By: Nick Maclaren (nmm) Date: 2006-07-13 10:35 Message: Logged In: YES user_id=42444 It's still there in Beta 2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1514428&group_id=5470 From noreply at sourceforge.net Wed Aug 23 10:46:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 01:46:19 -0700 Subject: [ python-Bugs-1544762 ] x!=y and [x]==[y] (!) Message-ID: Bugs item #1544762, was opened at 2006-08-22 17:51 Message generated for change (Comment added) made by charlesmerriam You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: x!=y and [x]==[y] (!) Initial Comment: Easy to obtain the weird behavior in the summary (in 2.5rc1 and earlier): >>> inf=1e9999 >>> x = y = inf/inf >>> x!=y and [x]==[y] True I propose to fix it by ensuring that lists (and tuples etc) compare their items with exactly the same logic as the == and != operators use. Alex (aleaxit at gmail.com) ---------------------------------------------------------------------- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-23 08:46 Message: Logged In: YES user_id=1581732 FYI: while not directly related, NaN comparisons keep making trouble. Per bug 1514428, python makes the mistake that inf > Nan should return false, just like Nan < inf. ---------------------------------------------------------------------- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-22 22:49 Message: Logged In: YES user_id=1581732 This appears to be a special oddity of NaN, which is a member of the set of "Things That Do Not Equal Themselves". 1. Are there any more members of this set? 2. Does this mean that any complex data type containing an integer is no a member of this set? 3. Is it odd that, say, a user's StatisticsArray will not equal itself if some statistic in the array is Nan? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 From noreply at sourceforge.net Wed Aug 23 16:20:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 07:20:49 -0700 Subject: [ python-Bugs-1495488 ] make altinstall installs pydoc Message-ID: Bugs item #1495488, was opened at 2006-05-26 14:19 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Heaney (theaney) Assigned to: Nobody/Anonymous (nobody) Summary: make altinstall installs pydoc Initial Comment: I did the "make altinstall" rather than the "make install" as suggested on http://www.python.org/download/releases/2.5/ This worked great, creating a /usr/local/bin/python2.5 which doesn't clash with my /usr/bin/python. However, it also created a /usr/local/bin/pydoc which did clash with my /usr/bin/pydoc. I just removed it and all is well. Should altinstall not create pydoc? It could create pydoc2.5 rather than pydoc, but then the shebang line would have to be changed to python2.5. What about smtpd.py, idle, and python-config, which were also created by altinstall? They don't currently conflict with anything I have for Python 2.4, but the potential is there for the same problem. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-08-23 16:20 Message: Logged In: YES user_id=21627 I don't think you have to pass the version to setup.py. Instead, setup.py can just use sys.version_info (since it is being run with the "right" interpreter). ---------------------------------------------------------------------- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-23 10:12 Message: Logged In: YES user_id=1581732 A bit more background; I'm starting to appreciate the problem. The makefile plays a part, but the real problem is down is down in Lib/distutils/command/install_scripts.py. Makefile/altinstall builds Makefile/sharedinstall executes setup.py imports distutils.core/setup() invokes indirectly distuitls.commands/install_scripts.py And install_scripts.py needs to be taught about the suffixes, or be passed a new destination filename. Note that setup() must be backward compatible back several versions. So it seems like the problems are: 1. Change the Makefile target sharedinstall to somehow pass the right suffix into setup. Also make sharedinstall alter the scripts to call the right version of python. 2. Change the Makefile target bininstall to add hard links for the scripts, e.g., from pydoc2.5 to pydoc. 3. Somehow pick up the parameters in Lib/distutils/commands/install_scripts.py and tack on the right suffix when copying. I'll whack at it tomorrow. ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2006-08-23 02:39 Message: Logged In: YES user_id=827666 Yeah, that's what the sed command is for. By the way, it looks like python-config is taken care of in release candidate 1. That is, after doing the altinstall for 2.5c1, I did # for file in pydoc idle smtpd.py; do mv $file ${file}2.5 sed -i 's@/usr/local/bin/python@/usr/local/bin/python2.5@' ${file}2.5 done to fix things up. ---------------------------------------------------------------------- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-23 01:50 Message: Logged In: YES user_id=1581732 Ah, it's a bit worse than that. Your /usr/loca/bin/pydoc would not have worked anyway. It's first line: #!/usr/local/bin/python would give an error because only /usr/local/bin/python2.5 exists. ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2006-06-22 02:14 Message: Logged In: YES user_id=827666 Sorry, I haven't had a chance to look at this again. I just installed Python-2.5b1 and it's still the same way. Here's what I did to fix things up after the make altinstall... # cd /usr/local/bin # for file in pydoc idle smtpd.py python-config; do mv $file ${file}2.5 sed -i 's@/usr/local/bin/python@/usr/local/bin/python2.5@' ${file}2.5 done Now, how to fix up the Makefile.pre and setup.py so this isn't necessary... ---------------------------------------------------------------------- Comment By: Tim Heaney (theaney) Date: 2006-06-06 13:19 Message: Logged In: YES user_id=827666 I'm not sure I know how. It looks like the downloaded files have the following shebang lines Tools/scripts/pydoc => #!/usr/bin/env python Tools/scripts/idle => #! /usr/bin/env python Lib/smtpd.py => #! /usr/bin/env python Misc/python-config.in => #!@BINDIR@/python whereas the installed files have /usr/local/bin/pydoc => #!/usr/local/bin/python /usr/local/bin/idle => #!/usr/local/bin/python /usr/local/bin/smtpd.py => #!/usr/local/bin/python /usr/local/bin/python-config => #!/usr/local/bin/python so they're already getting rewritten somewhere. We want both their names and their shebang lines to have the version /usr/local/bin/pydoc2.5 => #!/usr/local/bin/python2.5 /usr/local/bin/idle2.5 => #!/usr/local/bin/python2.5 /usr/local/bin/smtpd.py2.5 => #!/usr/local/bin/python2.5 /usr/local/bin/python-config2.5 => #!/usr/local/bin/python2.5 It seems that python-config appears in the Makefile, so adding something like sed -e "s, at BINDIR@,$(BINDIR)," < $(srcdir)/Misc/python-config.in >python-config$(VERSION)$(EXE) $(INSTALL_SCRIPT) python-config $(BINDIR)/python-config$(VERSION)$(EXE) rm python-config to Makefile.pre.in in an altlibainstall section or something might be all we need for that. The others are named in setup.py # Scripts to install scripts = ['Tools/scripts/pydoc', 'Tools/scripts/idle', 'Lib/smtpd.py'] but I haven't worked out where they get rewritten or installed yet. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-06-04 22:02 Message: Logged In: YES user_id=21627 You are right: altinstall shouldn't overwrite these conflicting files. For idle and pydoc, I would think that altinstall should install version-specific copies - users actually might want to run an idle or pydoc associated with a specific version, likewise for python-config. I'm uncertain why smtpd.py is installed at all. Would you be willing to work on a patch? You are right that the shebang line should get updated during the installation, too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1495488&group_id=5470 From noreply at sourceforge.net Wed Aug 23 16:49:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 07:49:52 -0700 Subject: [ python-Bugs-1545341 ] setup() keyword have to be list (doesn't work with tuple) Message-ID: Bugs item #1545341, was opened at 2006-08-23 16:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545341&group_id=5470 Please note that this 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: STINNER Victor (haypo) Assigned to: Nobody/Anonymous (nobody) Summary: setup() keyword have to be list (doesn't work with tuple) Initial Comment: Code: ====================== 8< ===================== from distutils.core import setup setup(..., classifier=('Intended Audience :: Developers', 'Environment :: Console :: Curses'), ...) ====================== 8< ===================== The query: "./setup.py register" will create HTML request: ----------------GHSKFJDLGDS7543FJKLFHRE75642756743254 Content-Disposition: form-data; name="classifiers" ('Intended Audience :: Developers', 'Environment :: Console :: Curses') Instead of a multipart part for each value. ==== The bug is stupid, see attached patch. Haypo ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545341&group_id=5470 From noreply at sourceforge.net Wed Aug 23 20:24:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 11:24:57 -0700 Subject: [ python-Bugs-1545463 ] New-style classes fail to cleanup attributes Message-ID: Bugs item #1545463, was opened at 2006-08-23 14:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 Please note that this 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: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: New-style classes fail to cleanup attributes Initial Comment: > cat x.py class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') class B: x = X('old') > python x.py creating X('new') creating X('old') deleting X('old') Python 2.4.2 (#2, Jan 13 2006, 12:00:38) Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 From noreply at sourceforge.net Wed Aug 23 21:37:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 12:37:28 -0700 Subject: [ python-Bugs-1545497 ] inconsistent treatment of NULs in int() Message-ID: Bugs item #1545497, was opened at 2006-08-23 12: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=1545497&group_id=5470 Please note that this 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: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: inconsistent treatment of NULs in int() Initial Comment: In int_new (Objects/intobject.c), embedded NUL chars are handled differently. We should check that the entire string is converted like PyNumber_Int(). int('5\0') raises an exception. int('5\0', 10) returns 5. >>> int('5\0', 10) 5 >>> int('5\0') Traceback (most recent call last): File "", line 1, in ValueError: null byte in argument for int() The difference is the explicit vs implicit base. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545497&group_id=5470 From noreply at sourceforge.net Thu Aug 24 00:01:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 15:01:16 -0700 Subject: [ python-Bugs-1545463 ] New-style classes fail to cleanup attributes Message-ID: Bugs item #1545463, was opened at 2006-08-23 14:24 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 Please note that this 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: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: New-style classes fail to cleanup attributes Initial Comment: > cat x.py class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') class B: x = X('old') > python x.py creating X('new') creating X('old') deleting X('old') Python 2.4.2 (#2, Jan 13 2006, 12:00:38) Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11) ---------------------------------------------------------------------- >Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 18:01 Message: Logged In: YES user_id=835142 It looks like the class object is not deleted alltogether: class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') del A Output: creating X('new') deleting X('new') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 From noreply at sourceforge.net Thu Aug 24 00:45:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 15:45:07 -0700 Subject: [ python-Bugs-1545463 ] New-style classes fail to cleanup attributes Message-ID: Bugs item #1545463, was opened at 2006-08-23 18:24 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 Please note that this 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: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: New-style classes fail to cleanup attributes Initial Comment: > cat x.py class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') class B: x = X('old') > python x.py creating X('new') creating X('old') deleting X('old') Python 2.4.2 (#2, Jan 13 2006, 12:00:38) Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-23 22:45 Message: Logged In: YES user_id=849994 Note that new-style classes are always part of a reference cycle (you can find this out via gc.get_referrers). Therefore, they will not be deleted instantly, but only after gc collects them (you can trigger that via gc.collect). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 22:01 Message: Logged In: YES user_id=835142 It looks like the class object is not deleted alltogether: class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') del A Output: creating X('new') deleting X('new') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 From noreply at sourceforge.net Thu Aug 24 00:54:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 15:54:17 -0700 Subject: [ python-Bugs-1545463 ] New-style classes fail to cleanup attributes Message-ID: Bugs item #1545463, was opened at 2006-08-23 14:24 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 Please note that this 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: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: New-style classes fail to cleanup attributes Initial Comment: > cat x.py class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') class B: x = X('old') > python x.py creating X('new') creating X('old') deleting X('old') Python 2.4.2 (#2, Jan 13 2006, 12:00:38) Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11) ---------------------------------------------------------------------- >Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 18:54 Message: Logged In: YES user_id=835142 Yes, I've found that (using gc.get_referrers!), but this does not explain why A is not cleaned up when the program exits. Note that if I put class A definition inside a function, it does get cleaned up. Must be some funny interation between module and new-style class objects. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-23 18:45 Message: Logged In: YES user_id=849994 Note that new-style classes are always part of a reference cycle (you can find this out via gc.get_referrers). Therefore, they will not be deleted instantly, but only after gc collects them (you can trigger that via gc.collect). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 18:01 Message: Logged In: YES user_id=835142 It looks like the class object is not deleted alltogether: class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') del A Output: creating X('new') deleting X('new') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 From noreply at sourceforge.net Thu Aug 24 01:18:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 16:18:41 -0700 Subject: [ python-Bugs-1545463 ] New-style classes fail to cleanup attributes Message-ID: Bugs item #1545463, was opened at 2006-08-23 18:24 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 Please note that this 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: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: New-style classes fail to cleanup attributes Initial Comment: > cat x.py class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') class B: x = X('old') > python x.py creating X('new') creating X('old') deleting X('old') Python 2.4.2 (#2, Jan 13 2006, 12:00:38) Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-23 23:18 Message: Logged In: YES user_id=849994 There's also this sentence in the __del__ docs: """ It is not guaranteed that __del__() methods are called for objects that still exist when the interpreter exits. """ ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 22:54 Message: Logged In: YES user_id=835142 Yes, I've found that (using gc.get_referrers!), but this does not explain why A is not cleaned up when the program exits. Note that if I put class A definition inside a function, it does get cleaned up. Must be some funny interation between module and new-style class objects. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-23 22:45 Message: Logged In: YES user_id=849994 Note that new-style classes are always part of a reference cycle (you can find this out via gc.get_referrers). Therefore, they will not be deleted instantly, but only after gc collects them (you can trigger that via gc.collect). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 22:01 Message: Logged In: YES user_id=835142 It looks like the class object is not deleted alltogether: class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') del A Output: creating X('new') deleting X('new') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 From noreply at sourceforge.net Thu Aug 24 02:08:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 17:08:42 -0700 Subject: [ python-Bugs-1545463 ] New-style classes fail to cleanup attributes Message-ID: Bugs item #1545463, was opened at 2006-08-23 14:24 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 Please note that this 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: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: New-style classes fail to cleanup attributes Initial Comment: > cat x.py class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') class B: x = X('old') > python x.py creating X('new') creating X('old') deleting X('old') Python 2.4.2 (#2, Jan 13 2006, 12:00:38) Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11) ---------------------------------------------------------------------- >Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 20:08 Message: Logged In: YES user_id=835142 I used __del__ just to illustrate the problem. In real life application, X was a type defined in a C module and I've noticed that it's tp_dealloc is not called on instances assigned to class variables. BTW, what are the circumstances when __del__() methods are not called for objects that still exist when the interpreter exits? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-23 19:18 Message: Logged In: YES user_id=849994 There's also this sentence in the __del__ docs: """ It is not guaranteed that __del__() methods are called for objects that still exist when the interpreter exits. """ ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 18:54 Message: Logged In: YES user_id=835142 Yes, I've found that (using gc.get_referrers!), but this does not explain why A is not cleaned up when the program exits. Note that if I put class A definition inside a function, it does get cleaned up. Must be some funny interation between module and new-style class objects. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-23 18:45 Message: Logged In: YES user_id=849994 Note that new-style classes are always part of a reference cycle (you can find this out via gc.get_referrers). Therefore, they will not be deleted instantly, but only after gc collects them (you can trigger that via gc.collect). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 18:01 Message: Logged In: YES user_id=835142 It looks like the class object is not deleted alltogether: class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') del A Output: creating X('new') deleting X('new') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 From noreply at sourceforge.net Thu Aug 24 03:15:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 18:15:29 -0700 Subject: [ python-Feature Requests-1006786 ] extend strptime to understand logging timestamps Message-ID: Feature Requests item #1006786, was opened at 2004-08-10 11:59 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1006786&group_id=5470 Please note that this 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: Skip Montanaro (montanaro) Assigned to: Brett Cannon (bcannon) Summary: extend strptime to understand logging timestamps Initial Comment: The default timestamp format used by the logging module appends a comma followed by a three-digit value representing milliseconds, e.g.: 2004-08-10 08:21:20,380 DEBUG log message here It would be nice if time.strptime() grokked this specification for the seconds in a timestamp so that applications which want to analyze log files can do so more easily. One possibility is to add a %s format specifier which recognizes NN,MMM as a floating point value containing fractional seconds with a comma as the "decimal point". Attached is a simple patch. I chose %s as the format sequence since it is related to %S. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-08-23 18:15 Message: Logged In: YES user_id=357491 Closing as rejected since this is not going to happen within strptime itself. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-11 11:17 Message: Logged In: YES user_id=357491 Jim is right; dateFormat() in the Formatter class in Lib/logging/ __init__.py seems to handle formatting of timestamps. Now looking at the code it seems to store the format in self.datefmt, but it is set to None by default. Then in dateFormat(), if self.datefmt is None it uses the default format. The problem is that the millisecond part of the timestamp is not supported by time tuples. strftime doesn't even support it (if you look at timeFormat(), it kind of cheats and passes everything *but* the millisecond time to strftime and then just tacks on the millisecond stamp) so it seems a little off to add support just in strptime. Kind of too bad since it means that there is no way to actually construct the default timestamp yourself; timeFormat, if given a value other than None just passes the format string through strftime. And look at datetime. It supports *microsecond* values in its time class and strftime can't support that either. So now we have two places in the stdlib where they use stuff that strftime (and thus strptime) can't support. And of course the logging module doesn't use datetime since it is keeping 1.5.2 compatibility, so we can't solve all our problems with just a fix for datetime or by subclassing stuff in _strptime and coming up with a custom strptime for the logging module. So honestly I don't know what a good solution would be since not having symmetry with strftime is not acceptable. I can only think of having a small wrapper function in the logging module that handles the millisecond part and passes the rest through strptime. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2004-08-11 08:59 Message: Logged In: YES user_id=764593 The format changes; "##,###" is just the default. It is based on an ISO recommendation, including the use of "," rather than "." to indicate a decimal point. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2004-08-10 20:22 Message: Logged In: YES user_id=44345 Whatever works. I hope we don't need a PEP for this. One way or the other I think it would be great if strptime can grok the logging module's timestamp. I haven't looked carefully at it to see if its timestamp format is variable or fixed. I suppose that will have a lot to do with how the parsing problem is solved in _strptime. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-10 18:43 Message: Logged In: YES user_id=357491 Is this the best solution, or would it be better to just have a specific logging module directive (either in the logging package or in strptime) that recognized the whole string? If that format *never* changes, then we could just simplify it by having a single directive to make life easier for everyone involved. If we are going to compromise on adding a special directive for the logging module might as well go all the way, right? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1006786&group_id=5470 From noreply at sourceforge.net Thu Aug 24 04:28:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 19:28:00 -0700 Subject: [ python-Bugs-1545658 ] distutils home scheme lacks python versioning Message-ID: Bugs item #1545658, was opened at 2006-08-24 02: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=1545658&group_id=5470 Please note that this 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: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils home scheme lacks python versioning Initial Comment: The "home scheme", as described here: http://docs.python.org/inst/alt-install-windows.html seems to be broken: no version suffix is appended, yet .pyc files are not guaranteed across Python revisions. Thus, breakage can occur. This is quite annoying, as an OS vendor often would like to install stuff into /usr/lib/python2.x/ (not using vendor-packages). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545658&group_id=5470 From noreply at sourceforge.net Thu Aug 24 04:28:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 19:28:46 -0700 Subject: [ python-Bugs-1545659 ] distutils needs vendor-packages support Message-ID: Bugs item #1545659, was opened at 2006-08-24 02:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545659&group_id=5470 Please note that this 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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: John Levon (movement) Assigned to: Nobody/Anonymous (nobody) Summary: distutils needs vendor-packages support Initial Comment: Currently, distutils supports "site-packages". It should also provide an option for "vendor-packages". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545659&group_id=5470 From noreply at sourceforge.net Thu Aug 24 05:14:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 20:14:44 -0700 Subject: [ python-Bugs-1545668 ] gcc trunk (4.2) exposes a signed integer overflows Message-ID: Bugs item #1545668, was opened at 2006-08-24 03: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=1545668&group_id=5470 Please note that this 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: Jack Howarth (jwhowarth) Assigned to: Jack Jansen (jackjansen) Summary: gcc trunk (4.2) exposes a signed integer overflows Initial Comment: While building python 2.4.3 with the current gcc trunk (soon to be 4.2), I uncovered a signed integer overflows bug in Python with the help of one of the gcc developers. The bug I observed is documented in this gcc mailing list message... http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html The gcc developer comments about its origin are in the messages... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00442.html which in short says... It *is* a bug in python, here is the proof: https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/ Objects/intobject.c?revision=25647&view=markup Function * i_divmod*(*register* *long* x, *register* *long* y, the following lines: / /* (-sys.maxint-1)/-1 is the only overflow case. *// *if* (y == -1 && x < 0 && x == -x) *return* DIVMOD_OVERFLOW; If overflow is barred then x==-x may happen only when x==0. This conflicts with x<0, which means that the compiler may assume that x<0 && x==-x always yields false. This may allow the compiler to eliminate the whole if statement. Hence, clearly python is at fault. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 From noreply at sourceforge.net Thu Aug 24 06:13:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 21:13:32 -0700 Subject: [ python-Bugs-1545668 ] gcc trunk (4.2) exposes a signed integer overflows Message-ID: Bugs item #1545668, was opened at 2006-08-24 03:14 Message generated for change (Comment added) made by jwhowarth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 Please note that this 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: Jack Howarth (jwhowarth) Assigned to: Jack Jansen (jackjansen) Summary: gcc trunk (4.2) exposes a signed integer overflows Initial Comment: While building python 2.4.3 with the current gcc trunk (soon to be 4.2), I uncovered a signed integer overflows bug in Python with the help of one of the gcc developers. The bug I observed is documented in this gcc mailing list message... http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html The gcc developer comments about its origin are in the messages... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00442.html which in short says... It *is* a bug in python, here is the proof: https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/ Objects/intobject.c?revision=25647&view=markup Function * i_divmod*(*register* *long* x, *register* *long* y, the following lines: / /* (-sys.maxint-1)/-1 is the only overflow case. *// *if* (y == -1 && x < 0 && x == -x) *return* DIVMOD_OVERFLOW; If overflow is barred then x==-x may happen only when x==0. This conflicts with x<0, which means that the compiler may assume that x<0 && x==-x always yields false. This may allow the compiler to eliminate the whole if statement. Hence, clearly python is at fault. ---------------------------------------------------------------------- >Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 04:13 Message: Logged In: YES user_id=403009 As suggested by another gcc developer in... http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html ...the following patch eliminates the error when python is built with gcc trunk... --- Python-2.4.3/Objects/intobject.c.org 2006-08-23 23:49:33.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-23 23:52:01.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned)x) == -(unsigned)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; This change allows python to completely pass its make check now when built with gcc trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 From noreply at sourceforge.net Thu Aug 24 07:07:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 22:07:18 -0700 Subject: [ python-Bugs-1545696 ] structmember T_LONG won't accept a python long Message-ID: Bugs item #1545696, was opened at 2006-08-24 00: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=1545696&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: structmember T_LONG won't accept a python long Initial Comment: An attribute defined as T_LONG throws a vague error when set to a python long, even when the value is within the range of a LONG. TypeError: bad argument type for built-in operation ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470 From noreply at sourceforge.net Thu Aug 24 08:43:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Aug 2006 23:43:52 -0700 Subject: [ python-Bugs-1117670 ] profiler: Bad return and Bad call errors with exceptions Message-ID: Bugs item #1117670, was opened at 2005-02-06 23:50 Message generated for change (Comment added) made by edloper You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117670&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Mueller (donut) Assigned to: Nobody/Anonymous (nobody) Summary: profiler: Bad return and Bad call errors with exceptions Initial Comment: I ran into a weird error when trying to profile a test script of mine: AssertionError: ('Bad call', ('', 0, 'encode')) I managed to whittle it down to some minimal test cases, which are attached (although the errors they generate are slightly different.) $ python-cvs -m profile profile_badcall.py Traceback (most recent call last): [snipped ...] File "/home/donut/usr64/python/lib/python2.5/profile.py", line 444, in runctx exec cmd in globals, locals File "", line 1, in ? File "profile_badcall.py", line 10, in ? os.path.join("C",'b') File "/home/donut/usr64/python/lib/python2.5/posixpath.py", line 56, in join def join(a, *p): File "/home/donut/usr64/python/lib/python2.5/profile.py", line 228, in trace_dispatch_i if self.dispatch[event](self, frame, t): File "/home/donut/usr64/python/lib/python2.5/profile.py", line 285, in trace_dispatch_call assert (self.cur is None or \ AssertionError: ('Bad call', ('profile_badcall.py', 2, 'trier')) $ python-cvs -m profile profile_badreturn.py Traceback (most recent call last): [snipped...] File "/home/donut/usr64/python/lib/python2.5/profile.py", line 444, in runctx exec cmd in globals, locals File "", line 1, in ? File "/home/donut/usr64/python/lib/python2.5/profile.py", line 228, in trace_dispatch_i if self.dispatch[event](self, frame, t): File "/home/donut/usr64/python/lib/python2.5/profile.py", line 312, in trace_dispatch_return assert frame is self.cur[-2].f_back, ("Bad return", self.cur[-3]) AssertionError: ('Bad return', ('profile_badreturn.py', 1, 'trier')) The errors occur in python CVS as of 20050206 and python 2.4, but not in python 2.3.4. OS: debian sid (3.1) Arch: amd64 ---------------------------------------------------------------------- >Comment By: Edward Loper (edloper) Date: 2006-08-24 02:43 Message: Logged In: YES user_id=195958 This bug was fixed by the following check-in: http://mail.python.org/pipermail/python-checkins/2005- September/047099.html It should be closed. A work-around for people using older versions of 2.4 is to do: from profile import Profile Profile.dispatch['c_exception'] = \ Profile.trace_dispatch_return ---------------------------------------------------------------------- Comment By: Artur de Sousa Rocha (adsr) Date: 2006-02-04 18:47 Message: Logged In: YES user_id=728207 I've run into this bug too and decided to check the test cases. Here's what I found: 1) Both test cases fail as mentioned above under Cygwin. 2) Under native Windows Python, profile_badcall.py passes OK and profile_badreturn.py gives the following traceback: Traceback (most recent call last): File "c:\Python24\lib\profile.py", line 611, in ? run('execfile(%r)' % (sys.argv[0],), options.outfile, options.sort) File "c:\Python24\lib\profile.py", line 72, in run prof = prof.run(statement) File "c:\Python24\lib\profile.py", line 448, in run return self.runctx(cmd, dict, dict) File "c:\Python24\lib\profile.py", line 454, in runctx exec cmd in globals, locals File "", line 1, in ? File "profile_badreturn.py", line 9, in ? sum(1,0) TypeError: iteration over non-sequence Python versions used: Python 2.4.1 (#1, May 27 2005, 18:02:40) [GCC 3.3.3 (cygwin special)] on cygwin Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on win32 ---------------------------------------------------------------------- Comment By: Andrew Bennetts (spiv) Date: 2005-10-08 03:05 Message: Logged In: YES user_id=50945 I still see this in current python 2.4, but not in current python CVS. Also, hotshot seems to work ok in 2.4 and CVS. OS: ubuntu breezy (5.10) Arch: i386 ---------------------------------------------------------------------- Comment By: Gary Oberbrunner (garyoberbrunner) Date: 2005-03-08 22:35 Message: Logged In: YES user_id=417980 Is there any news on this bug? It is possibly preventing scons (http://scons.org) from being profiled on python 2.4 -- we get the same errors as above. Test case is too large to include here, but please email me with any news if possible! Would be glad to test a fix. -- Gary ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117670&group_id=5470 From noreply at sourceforge.net Thu Aug 24 11:14:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 02:14:01 -0700 Subject: [ python-Bugs-1545668 ] gcc trunk (4.2) exposes a signed integer overflows Message-ID: Bugs item #1545668, was opened at 2006-08-24 05:14 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 Please note that this 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: Jack Howarth (jwhowarth) >Assigned to: Nobody/Anonymous (nobody) Summary: gcc trunk (4.2) exposes a signed integer overflows Initial Comment: While building python 2.4.3 with the current gcc trunk (soon to be 4.2), I uncovered a signed integer overflows bug in Python with the help of one of the gcc developers. The bug I observed is documented in this gcc mailing list message... http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html The gcc developer comments about its origin are in the messages... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00442.html which in short says... It *is* a bug in python, here is the proof: https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/ Objects/intobject.c?revision=25647&view=markup Function * i_divmod*(*register* *long* x, *register* *long* y, the following lines: / /* (-sys.maxint-1)/-1 is the only overflow case. *// *if* (y == -1 && x < 0 && x == -x) *return* DIVMOD_OVERFLOW; If overflow is barred then x==-x may happen only when x==0. This conflicts with x<0, which means that the compiler may assume that x<0 && x==-x always yields false. This may allow the compiler to eliminate the whole if statement. Hence, clearly python is at fault. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 11:14 Message: Logged In: YES user_id=45365 I don't think this is a mac-specific bug, and I'm also not really the right person to look into this... ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 06:13 Message: Logged In: YES user_id=403009 As suggested by another gcc developer in... http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html ...the following patch eliminates the error when python is built with gcc trunk... --- Python-2.4.3/Objects/intobject.c.org 2006-08-23 23:49:33.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-23 23:52:01.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned)x) == -(unsigned)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; This change allows python to completely pass its make check now when built with gcc trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 From noreply at sourceforge.net Thu Aug 24 11:46:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 02:46:57 -0700 Subject: [ python-Bugs-1545836 ] Incomplete info in 7.18.1 ZipFile Objects Message-ID: Bugs item #1545836, was opened at 2006-08-24 09: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=1545836&group_id=5470 Please note that this 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: Taco (tacotortilla) Assigned to: Nobody/Anonymous (nobody) Summary: Incomplete info in 7.18.1 ZipFile Objects Initial Comment: Documentation: Python Library Reference 2.4.3 7.18.1 ZipFile Objects The description for class ZipFile(file[, mode[, compression]]) states the possible values for the parameter "compression", but does not give any details on what they do. A nice table like this one would be prudent: ZIP_STORED Files stored with no compression ZIP_DEFLATED Files stored with zlib "deflate" compression Cheers ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545836&group_id=5470 From noreply at sourceforge.net Thu Aug 24 11:49:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 02:49:37 -0700 Subject: [ python-Bugs-1545837 ] array.array borks on deepcopy Message-ID: Bugs item #1545837, was opened at 2006-08-24 11:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&group_id=5470 Please note that this 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: Václav Haisman (wilx) Assigned to: Nobody/Anonymous (nobody) Summary: array.array borks on deepcopy Initial Comment: Hi, I think there is a bug arraymodule.c this line: {"__deepcopy__",(PyCFunction)array_copy, METH_NOARGS, copy_doc}, should probably have METH_O instead of METH_NOARGS there, since according to docs and the prototype of the array_copy() function there is one parameter. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&group_id=5470 From noreply at sourceforge.net Thu Aug 24 13:22:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 04:22:40 -0700 Subject: [ python-Bugs-1545668 ] gcc trunk (4.2) exposes a signed integer overflows Message-ID: Bugs item #1545668, was opened at 2006-08-24 03:14 Message generated for change (Comment added) made by jwhowarth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 Please note that this 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: Jack Howarth (jwhowarth) Assigned to: Nobody/Anonymous (nobody) Summary: gcc trunk (4.2) exposes a signed integer overflows Initial Comment: While building python 2.4.3 with the current gcc trunk (soon to be 4.2), I uncovered a signed integer overflows bug in Python with the help of one of the gcc developers. The bug I observed is documented in this gcc mailing list message... http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html The gcc developer comments about its origin are in the messages... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00442.html which in short says... It *is* a bug in python, here is the proof: https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/ Objects/intobject.c?revision=25647&view=markup Function * i_divmod*(*register* *long* x, *register* *long* y, the following lines: / /* (-sys.maxint-1)/-1 is the only overflow case. *// *if* (y == -1 && x < 0 && x == -x) *return* DIVMOD_OVERFLOW; If overflow is barred then x==-x may happen only when x==0. This conflicts with x<0, which means that the compiler may assume that x<0 && x==-x always yields false. This may allow the compiler to eliminate the whole if statement. Hence, clearly python is at fault. ---------------------------------------------------------------------- >Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 11:22 Message: Logged In: YES user_id=403009 The was a few other comments from the gcc developers on the proposed fix... http://gcc.gnu.org/ml/gcc/2006-08/msg00448.html http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html ...so that since x is a long the more correct fix is... --- Python-2.4.3/Objects/intobject.c.org 2006-08-24 07:06:51.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-24 07:08:06.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned long)x) == -(unsigned long)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; I have tested this form of the patch and it works as well. My main concern is that we get this fix in python 2.5 before release. Jack, could you reassign this to the person you think might be most appropriate out of the list of python developers? I really should be a pretty simple review for the patch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 09:14 Message: Logged In: YES user_id=45365 I don't think this is a mac-specific bug, and I'm also not really the right person to look into this... ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 04:13 Message: Logged In: YES user_id=403009 As suggested by another gcc developer in... http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html ...the following patch eliminates the error when python is built with gcc trunk... --- Python-2.4.3/Objects/intobject.c.org 2006-08-23 23:49:33.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-23 23:52:01.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned)x) == -(unsigned)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; This change allows python to completely pass its make check now when built with gcc trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 From noreply at sourceforge.net Thu Aug 24 13:26:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 04:26:51 -0700 Subject: [ python-Bugs-1544762 ] x!=y and [x]==[y] (!) Message-ID: Bugs item #1544762, was opened at 2006-08-22 19:51 Message generated for change (Comment added) made by sgala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: x!=y and [x]==[y] (!) Initial Comment: Easy to obtain the weird behavior in the summary (in 2.5rc1 and earlier): >>> inf=1e9999 >>> x = y = inf/inf >>> x!=y and [x]==[y] True I propose to fix it by ensuring that lists (and tuples etc) compare their items with exactly the same logic as the == and != operators use. Alex (aleaxit at gmail.com) ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-24 13:26 Message: Logged In: YES user_id=178886 This is a consequence of the way list equality is implemented. Counterexample: >>> inf=1e9999 >>> x=inf/inf >>> y=inf/inf >>> x!=y and [x] == [y] False i.e. [x] == [y] iff x is y strings are interned in python (so 'a' is chr(97) returns True), and ints (so 1+1 is 1+1 returns True) but not floats (so inf/inf is inf/inf returns False). Interning floats (or at least "special" numbers, such as nan or inf) could make sense, but I guess this is a RFE, and not a bug, and a different one. ---------------------------------------------------------------------- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-23 10:46 Message: Logged In: YES user_id=1581732 FYI: while not directly related, NaN comparisons keep making trouble. Per bug 1514428, python makes the mistake that inf > Nan should return false, just like Nan < inf. ---------------------------------------------------------------------- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-23 00:49 Message: Logged In: YES user_id=1581732 This appears to be a special oddity of NaN, which is a member of the set of "Things That Do Not Equal Themselves". 1. Are there any more members of this set? 2. Does this mean that any complex data type containing an integer is no a member of this set? 3. Is it odd that, say, a user's StatisticsArray will not equal itself if some statistic in the array is Nan? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 From noreply at sourceforge.net Thu Aug 24 13:32:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 04:32:46 -0700 Subject: [ python-Bugs-1544762 ] x!=y and [x]==[y] (!) Message-ID: Bugs item #1544762, was opened at 2006-08-22 19:51 Message generated for change (Comment added) made by sgala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: x!=y and [x]==[y] (!) Initial Comment: Easy to obtain the weird behavior in the summary (in 2.5rc1 and earlier): >>> inf=1e9999 >>> x = y = inf/inf >>> x!=y and [x]==[y] True I propose to fix it by ensuring that lists (and tuples etc) compare their items with exactly the same logic as the == and != operators use. Alex (aleaxit at gmail.com) ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-24 13:32 Message: Logged In: YES user_id=178886 comparing tuples by == on elements, instead of "is", would break tuple inmutability and make them unsuitable for keys, BTW. Doing the same with lists would make them behave different to tuples. Liskov and Guttag (Addison Wesley, 2001) book has and interesting discussion on equality in collections, and how java's model has problems (as basically any model with mutable objects that hash on content instead of identity). Python has been doing it right for a lot of time. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-24 13:26 Message: Logged In: YES user_id=178886 This is a consequence of the way list equality is implemented. Counterexample: >>> inf=1e9999 >>> x=inf/inf >>> y=inf/inf >>> x!=y and [x] == [y] False i.e. [x] == [y] iff x is y strings are interned in python (so 'a' is chr(97) returns True), and ints (so 1+1 is 1+1 returns True) but not floats (so inf/inf is inf/inf returns False). Interning floats (or at least "special" numbers, such as nan or inf) could make sense, but I guess this is a RFE, and not a bug, and a different one. ---------------------------------------------------------------------- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-23 10:46 Message: Logged In: YES user_id=1581732 FYI: while not directly related, NaN comparisons keep making trouble. Per bug 1514428, python makes the mistake that inf > Nan should return false, just like Nan < inf. ---------------------------------------------------------------------- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-23 00:49 Message: Logged In: YES user_id=1581732 This appears to be a special oddity of NaN, which is a member of the set of "Things That Do Not Equal Themselves". 1. Are there any more members of this set? 2. Does this mean that any complex data type containing an integer is no a member of this set? 3. Is it odd that, say, a user's StatisticsArray will not equal itself if some statistic in the array is Nan? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 From noreply at sourceforge.net Thu Aug 24 16:37:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 07:37:24 -0700 Subject: [ python-Bugs-1545668 ] gcc trunk (4.2) exposes a signed integer overflows Message-ID: Bugs item #1545668, was opened at 2006-08-24 05:14 Message generated for change (Comment added) made by jackjansen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 Please note that this 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: Jack Howarth (jwhowarth) >Assigned to: Neal Norwitz (nnorwitz) Summary: gcc trunk (4.2) exposes a signed integer overflows Initial Comment: While building python 2.4.3 with the current gcc trunk (soon to be 4.2), I uncovered a signed integer overflows bug in Python with the help of one of the gcc developers. The bug I observed is documented in this gcc mailing list message... http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html The gcc developer comments about its origin are in the messages... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00442.html which in short says... It *is* a bug in python, here is the proof: https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/ Objects/intobject.c?revision=25647&view=markup Function * i_divmod*(*register* *long* x, *register* *long* y, the following lines: / /* (-sys.maxint-1)/-1 is the only overflow case. *// *if* (y == -1 && x < 0 && x == -x) *return* DIVMOD_OVERFLOW; If overflow is barred then x==-x may happen only when x==0. This conflicts with x<0, which means that the compiler may assume that x<0 && x==-x always yields false. This may allow the compiler to eliminate the whole if statement. Hence, clearly python is at fault. ---------------------------------------------------------------------- >Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 16:37 Message: Logged In: YES user_id=45365 Hmm... intobject.c doesn't really have a "champion"... Neal, I'm assigning this to you purely on the ground that you're the last person to have edited this file. Feel free to pass on (but not back:-). ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 13:22 Message: Logged In: YES user_id=403009 The was a few other comments from the gcc developers on the proposed fix... http://gcc.gnu.org/ml/gcc/2006-08/msg00448.html http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html ...so that since x is a long the more correct fix is... --- Python-2.4.3/Objects/intobject.c.org 2006-08-24 07:06:51.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-24 07:08:06.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned long)x) == -(unsigned long)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; I have tested this form of the patch and it works as well. My main concern is that we get this fix in python 2.5 before release. Jack, could you reassign this to the person you think might be most appropriate out of the list of python developers? I really should be a pretty simple review for the patch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 11:14 Message: Logged In: YES user_id=45365 I don't think this is a mac-specific bug, and I'm also not really the right person to look into this... ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 06:13 Message: Logged In: YES user_id=403009 As suggested by another gcc developer in... http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html ...the following patch eliminates the error when python is built with gcc trunk... --- Python-2.4.3/Objects/intobject.c.org 2006-08-23 23:49:33.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-23 23:52:01.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned)x) == -(unsigned)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; This change allows python to completely pass its make check now when built with gcc trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 From noreply at sourceforge.net Thu Aug 24 16:54:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 07:54:07 -0700 Subject: [ python-Bugs-1545668 ] gcc trunk (4.2) exposes a signed integer overflows Message-ID: Bugs item #1545668, was opened at 2006-08-23 20:14 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 Please note that this 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: Jack Howarth (jwhowarth) >Assigned to: Tim Peters (tim_one) Summary: gcc trunk (4.2) exposes a signed integer overflows Initial Comment: While building python 2.4.3 with the current gcc trunk (soon to be 4.2), I uncovered a signed integer overflows bug in Python with the help of one of the gcc developers. The bug I observed is documented in this gcc mailing list message... http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html The gcc developer comments about its origin are in the messages... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00442.html which in short says... It *is* a bug in python, here is the proof: https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/ Objects/intobject.c?revision=25647&view=markup Function * i_divmod*(*register* *long* x, *register* *long* y, the following lines: / /* (-sys.maxint-1)/-1 is the only overflow case. *// *if* (y == -1 && x < 0 && x == -x) *return* DIVMOD_OVERFLOW; If overflow is barred then x==-x may happen only when x==0. This conflicts with x<0, which means that the compiler may assume that x<0 && x==-x always yields false. This may allow the compiler to eliminate the whole if statement. Hence, clearly python is at fault. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 07:54 Message: Logged In: YES user_id=33168 Assigning to Tim, he likes these problems. :-) He recently fixed a similar problem in another piece of code. I'm going to try to grep and see if I can find more occurrences of this. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 07:37 Message: Logged In: YES user_id=45365 Hmm... intobject.c doesn't really have a "champion"... Neal, I'm assigning this to you purely on the ground that you're the last person to have edited this file. Feel free to pass on (but not back:-). ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 04:22 Message: Logged In: YES user_id=403009 The was a few other comments from the gcc developers on the proposed fix... http://gcc.gnu.org/ml/gcc/2006-08/msg00448.html http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html ...so that since x is a long the more correct fix is... --- Python-2.4.3/Objects/intobject.c.org 2006-08-24 07:06:51.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-24 07:08:06.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned long)x) == -(unsigned long)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; I have tested this form of the patch and it works as well. My main concern is that we get this fix in python 2.5 before release. Jack, could you reassign this to the person you think might be most appropriate out of the list of python developers? I really should be a pretty simple review for the patch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 02:14 Message: Logged In: YES user_id=45365 I don't think this is a mac-specific bug, and I'm also not really the right person to look into this... ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-23 21:13 Message: Logged In: YES user_id=403009 As suggested by another gcc developer in... http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html ...the following patch eliminates the error when python is built with gcc trunk... --- Python-2.4.3/Objects/intobject.c.org 2006-08-23 23:49:33.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-23 23:52:01.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned)x) == -(unsigned)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; This change allows python to completely pass its make check now when built with gcc trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 From noreply at sourceforge.net Thu Aug 24 16:54:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 07:54:24 -0700 Subject: [ python-Bugs-1545668 ] gcc trunk (4.2) exposes a signed integer overflows Message-ID: Bugs item #1545668, was opened at 2006-08-24 05:14 Message generated for change (Comment added) made by sjoerd You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 Please note that this 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: Jack Howarth (jwhowarth) >Assigned to: Neal Norwitz (nnorwitz) Summary: gcc trunk (4.2) exposes a signed integer overflows Initial Comment: While building python 2.4.3 with the current gcc trunk (soon to be 4.2), I uncovered a signed integer overflows bug in Python with the help of one of the gcc developers. The bug I observed is documented in this gcc mailing list message... http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html The gcc developer comments about its origin are in the messages... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00442.html which in short says... It *is* a bug in python, here is the proof: https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/ Objects/intobject.c?revision=25647&view=markup Function * i_divmod*(*register* *long* x, *register* *long* y, the following lines: / /* (-sys.maxint-1)/-1 is the only overflow case. *// *if* (y == -1 && x < 0 && x == -x) *return* DIVMOD_OVERFLOW; If overflow is barred then x==-x may happen only when x==0. This conflicts with x<0, which means that the compiler may assume that x<0 && x==-x always yields false. This may allow the compiler to eliminate the whole if statement. Hence, clearly python is at fault. ---------------------------------------------------------------------- >Comment By: Sjoerd Mullender (sjoerd) Date: 2006-08-24 16:54 Message: Logged In: YES user_id=43607 Just a comment, I'm not claiming this bug. The test (x < 0 && x == -x) tests whether x is equal to the smallest negative number. If x is equal to -2147483648, then -x is also equal to -2147483648 due to overflow. What does this version of gcc do with this code when x = -2147483648? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 16:54 Message: Logged In: YES user_id=33168 Assigning to Tim, he likes these problems. :-) He recently fixed a similar problem in another piece of code. I'm going to try to grep and see if I can find more occurrences of this. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 16:37 Message: Logged In: YES user_id=45365 Hmm... intobject.c doesn't really have a "champion"... Neal, I'm assigning this to you purely on the ground that you're the last person to have edited this file. Feel free to pass on (but not back:-). ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 13:22 Message: Logged In: YES user_id=403009 The was a few other comments from the gcc developers on the proposed fix... http://gcc.gnu.org/ml/gcc/2006-08/msg00448.html http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html ...so that since x is a long the more correct fix is... --- Python-2.4.3/Objects/intobject.c.org 2006-08-24 07:06:51.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-24 07:08:06.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned long)x) == -(unsigned long)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; I have tested this form of the patch and it works as well. My main concern is that we get this fix in python 2.5 before release. Jack, could you reassign this to the person you think might be most appropriate out of the list of python developers? I really should be a pretty simple review for the patch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 11:14 Message: Logged In: YES user_id=45365 I don't think this is a mac-specific bug, and I'm also not really the right person to look into this... ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 06:13 Message: Logged In: YES user_id=403009 As suggested by another gcc developer in... http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html ...the following patch eliminates the error when python is built with gcc trunk... --- Python-2.4.3/Objects/intobject.c.org 2006-08-23 23:49:33.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-23 23:52:01.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned)x) == -(unsigned)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; This change allows python to completely pass its make check now when built with gcc trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 From noreply at sourceforge.net Thu Aug 24 17:00:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 08:00:42 -0700 Subject: [ python-Bugs-1545668 ] gcc trunk (4.2) exposes a signed integer overflows Message-ID: Bugs item #1545668, was opened at 2006-08-23 20:14 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 Please note that this 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: Jack Howarth (jwhowarth) >Assigned to: Tim Peters (tim_one) Summary: gcc trunk (4.2) exposes a signed integer overflows Initial Comment: While building python 2.4.3 with the current gcc trunk (soon to be 4.2), I uncovered a signed integer overflows bug in Python with the help of one of the gcc developers. The bug I observed is documented in this gcc mailing list message... http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html The gcc developer comments about its origin are in the messages... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00442.html which in short says... It *is* a bug in python, here is the proof: https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/ Objects/intobject.c?revision=25647&view=markup Function * i_divmod*(*register* *long* x, *register* *long* y, the following lines: / /* (-sys.maxint-1)/-1 is the only overflow case. *// *if* (y == -1 && x < 0 && x == -x) *return* DIVMOD_OVERFLOW; If overflow is barred then x==-x may happen only when x==0. This conflicts with x<0, which means that the compiler may assume that x<0 && x==-x always yields false. This may allow the compiler to eliminate the whole if statement. Hence, clearly python is at fault. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 08:00 Message: Logged In: YES user_id=33168 I grepped for ' == .*-[^1>]' and ' != .*-[^1>]' and didn't spot any other occurrences. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2006-08-24 07:54 Message: Logged In: YES user_id=43607 Just a comment, I'm not claiming this bug. The test (x < 0 && x == -x) tests whether x is equal to the smallest negative number. If x is equal to -2147483648, then -x is also equal to -2147483648 due to overflow. What does this version of gcc do with this code when x = -2147483648? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 07:54 Message: Logged In: YES user_id=33168 Assigning to Tim, he likes these problems. :-) He recently fixed a similar problem in another piece of code. I'm going to try to grep and see if I can find more occurrences of this. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 07:37 Message: Logged In: YES user_id=45365 Hmm... intobject.c doesn't really have a "champion"... Neal, I'm assigning this to you purely on the ground that you're the last person to have edited this file. Feel free to pass on (but not back:-). ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 04:22 Message: Logged In: YES user_id=403009 The was a few other comments from the gcc developers on the proposed fix... http://gcc.gnu.org/ml/gcc/2006-08/msg00448.html http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html ...so that since x is a long the more correct fix is... --- Python-2.4.3/Objects/intobject.c.org 2006-08-24 07:06:51.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-24 07:08:06.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned long)x) == -(unsigned long)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; I have tested this form of the patch and it works as well. My main concern is that we get this fix in python 2.5 before release. Jack, could you reassign this to the person you think might be most appropriate out of the list of python developers? I really should be a pretty simple review for the patch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 02:14 Message: Logged In: YES user_id=45365 I don't think this is a mac-specific bug, and I'm also not really the right person to look into this... ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-23 21:13 Message: Logged In: YES user_id=403009 As suggested by another gcc developer in... http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html ...the following patch eliminates the error when python is built with gcc trunk... --- Python-2.4.3/Objects/intobject.c.org 2006-08-23 23:49:33.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-23 23:52:01.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned)x) == -(unsigned)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; This change allows python to completely pass its make check now when built with gcc trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 From noreply at sourceforge.net Thu Aug 24 17:22:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 08:22:22 -0700 Subject: [ python-Bugs-1545668 ] gcc trunk (4.2) exposes a signed integer overflows Message-ID: Bugs item #1545668, was opened at 2006-08-24 03:14 Message generated for change (Comment added) made by jwhowarth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 Please note that this 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: Jack Howarth (jwhowarth) Assigned to: Tim Peters (tim_one) Summary: gcc trunk (4.2) exposes a signed integer overflows Initial Comment: While building python 2.4.3 with the current gcc trunk (soon to be 4.2), I uncovered a signed integer overflows bug in Python with the help of one of the gcc developers. The bug I observed is documented in this gcc mailing list message... http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html The gcc developer comments about its origin are in the messages... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00442.html which in short says... It *is* a bug in python, here is the proof: https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/ Objects/intobject.c?revision=25647&view=markup Function * i_divmod*(*register* *long* x, *register* *long* y, the following lines: / /* (-sys.maxint-1)/-1 is the only overflow case. *// *if* (y == -1 && x < 0 && x == -x) *return* DIVMOD_OVERFLOW; If overflow is barred then x==-x may happen only when x==0. This conflicts with x<0, which means that the compiler may assume that x<0 && x==-x always yields false. This may allow the compiler to eliminate the whole if statement. Hence, clearly python is at fault. ---------------------------------------------------------------------- >Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 15:22 Message: Logged In: YES user_id=403009 Everyone involved in reviewing this patch should definitely read the following sequence of gcc mailing list messages which show the process by which this patch was arrived at... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html http://gcc.gnu.org/ml/gcc/2006-08/msg00437.html http://gcc.gnu.org/ml/gcc/2006-08/msg00443.html http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html http://gcc.gnu.org/ml/gcc/2006-08/msg00447.html http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html So we have had lots of gcc developer eyes on this problem and they all agree on the flaw and the fix as posted. It's unfortunate that I had to abuse their mailing list to get this addressed before python 2.5 gets released. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 15:00 Message: Logged In: YES user_id=33168 I grepped for ' == .*-[^1>]' and ' != .*-[^1>]' and didn't spot any other occurrences. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2006-08-24 14:54 Message: Logged In: YES user_id=43607 Just a comment, I'm not claiming this bug. The test (x < 0 && x == -x) tests whether x is equal to the smallest negative number. If x is equal to -2147483648, then -x is also equal to -2147483648 due to overflow. What does this version of gcc do with this code when x = -2147483648? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 14:54 Message: Logged In: YES user_id=33168 Assigning to Tim, he likes these problems. :-) He recently fixed a similar problem in another piece of code. I'm going to try to grep and see if I can find more occurrences of this. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 14:37 Message: Logged In: YES user_id=45365 Hmm... intobject.c doesn't really have a "champion"... Neal, I'm assigning this to you purely on the ground that you're the last person to have edited this file. Feel free to pass on (but not back:-). ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 11:22 Message: Logged In: YES user_id=403009 The was a few other comments from the gcc developers on the proposed fix... http://gcc.gnu.org/ml/gcc/2006-08/msg00448.html http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html ...so that since x is a long the more correct fix is... --- Python-2.4.3/Objects/intobject.c.org 2006-08-24 07:06:51.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-24 07:08:06.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned long)x) == -(unsigned long)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; I have tested this form of the patch and it works as well. My main concern is that we get this fix in python 2.5 before release. Jack, could you reassign this to the person you think might be most appropriate out of the list of python developers? I really should be a pretty simple review for the patch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 09:14 Message: Logged In: YES user_id=45365 I don't think this is a mac-specific bug, and I'm also not really the right person to look into this... ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 04:13 Message: Logged In: YES user_id=403009 As suggested by another gcc developer in... http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html ...the following patch eliminates the error when python is built with gcc trunk... --- Python-2.4.3/Objects/intobject.c.org 2006-08-23 23:49:33.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-23 23:52:01.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned)x) == -(unsigned)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; This change allows python to completely pass its make check now when built with gcc trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 From noreply at sourceforge.net Thu Aug 24 17:38:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 08:38:33 -0700 Subject: [ python-Bugs-1546052 ] PyString_FromString() clarification Message-ID: Bugs item #1546052, was opened at 2006-08-24 17: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=1546052&group_id=5470 Please note that this 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: Christian Walther (cwalther) Assigned to: Nobody/Anonymous (nobody) Summary: PyString_FromString() clarification Initial Comment: The documentation for PyObject* PyString_FromString( const char *v) in the "Python/C API Reference Manual, 29 March 2006, Release 2.4.3", section 7.3.1 "String Objects" , does not mention whether this function makes a copy of the passed C string or just keeps the pointer. Google provides some posts on various mailing lists and forums that seem to indicate that it indeed does copy the string (which is the right thing to do, of course). Could something like to following be added to the documentation? "This function makes a copy of the string pointed to by v, so you may modify or deallocate it afterwards without affecting the Python object created by this function." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546052&group_id=5470 From noreply at sourceforge.net Thu Aug 24 20:30:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 11:30:51 -0700 Subject: [ python-Bugs-1545696 ] structmember T_LONG won't accept a python long Message-ID: Bugs item #1545696, was opened at 2006-08-23 22:07 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: structmember T_LONG won't accept a python long Initial Comment: An attribute defined as T_LONG throws a vague error when set to a python long, even when the value is within the range of a LONG. TypeError: bad argument type for built-in operation ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 11:30 Message: Logged In: YES user_id=33168 Can you provide example code that demonstrates what you mean? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470 From noreply at sourceforge.net Thu Aug 24 20:50:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 11:50:55 -0700 Subject: [ python-Bugs-1545837 ] array.array borks on deepcopy Message-ID: Bugs item #1545837, was opened at 2006-08-24 11:49 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&group_id=5470 Please note that this 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: Later >Priority: 7 Submitted By: V?clav Haisman (wilx) Assigned to: Nobody/Anonymous (nobody) Summary: array.array borks on deepcopy Initial Comment: Hi, I think there is a bug arraymodule.c this line: {"__deepcopy__",(PyCFunction)array_copy, METH_NOARGS, copy_doc}, should probably have METH_O instead of METH_NOARGS there, since according to docs and the prototype of the array_copy() function there is one parameter. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-08-24 20:50 Message: Logged In: YES user_id=34209 Thanks! Fixed in the trunk (which is 2.6-to-be) revision 51565, and it will also be fixed for Python 2.4.4 and 2.5.1. It's unfortunately just a bit too late for 2.5.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&group_id=5470 From noreply at sourceforge.net Thu Aug 24 21:30:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 12:30:19 -0700 Subject: [ python-Bugs-1546203 ] bcannon secure branch issues Message-ID: Bugs item #1546203, was opened at 2006-08-24 15:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546203&group_id=5470 Please note that this 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: 3rd Party Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: bcannon secure branch issues Initial Comment: Referring to http://svn.python.org/view/python/ branches/bcannon-sandboxing/ securing_python.txt?view=markup but there doesn't seem to be a group/category for feedback on branches. The sys module should *not* be shared between interpreters, even though it is an extension module. (If need be, each sys module can be a proxy that itself imports from the "real" sys.) sys should probably also be filled explicitly on creation, like builtins. (And the same for os, os.path?) Note that this will affect which sys.attributes should be available (perhaps read-only) or hidden by default - - and that should really only be by default. For specific examples: + some programs modify sys.argv to communicated between modules. So long as the initial value of sys.argv is set to something sufficiently discreet, there should be no problem letting them continue to do so. + The current draft hides sys.subversion (revealing unpatched bugs?) but shows sys.version (which reveals the same information, at a coarser grain). + getdefaultencoding may compromise privacy information, particularly for smaller languages. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546203&group_id=5470 From noreply at sourceforge.net Thu Aug 24 21:31:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 12:31:33 -0700 Subject: [ python-Bugs-1546203 ] bcannon secure branch issues Message-ID: Bugs item #1546203, was opened at 2006-08-24 15:30 Message generated for change (Settings changed) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546203&group_id=5470 Please note that this 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: 3rd Party Status: Open Resolution: None Priority: 5 Submitted By: Jim Jewett (jimjjewett) >Assigned to: Brett Cannon (bcannon) Summary: bcannon secure branch issues Initial Comment: Referring to http://svn.python.org/view/python/ branches/bcannon-sandboxing/ securing_python.txt?view=markup but there doesn't seem to be a group/category for feedback on branches. The sys module should *not* be shared between interpreters, even though it is an extension module. (If need be, each sys module can be a proxy that itself imports from the "real" sys.) sys should probably also be filled explicitly on creation, like builtins. (And the same for os, os.path?) Note that this will affect which sys.attributes should be available (perhaps read-only) or hidden by default - - and that should really only be by default. For specific examples: + some programs modify sys.argv to communicated between modules. So long as the initial value of sys.argv is set to something sufficiently discreet, there should be no problem letting them continue to do so. + The current draft hides sys.subversion (revealing unpatched bugs?) but shows sys.version (which reveals the same information, at a coarser grain). + getdefaultencoding may compromise privacy information, particularly for smaller languages. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546203&group_id=5470 From noreply at sourceforge.net Thu Aug 24 21:56:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 12:56:00 -0700 Subject: [ python-Bugs-1545696 ] structmember T_LONG won't accept a python long Message-ID: Bugs item #1545696, was opened at 2006-08-24 00:07 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: structmember T_LONG won't accept a python long Initial Comment: An attribute defined as T_LONG throws a vague error when set to a python long, even when the value is within the range of a LONG. TypeError: bad argument type for built-in operation ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-08-24 14:56 Message: Logged In: YES user_id=771074 The DEVMODE object from pywintypes has attributes defined as T_LONG via the structmember API. >>> import pywintypes >>> dm=pywintypes.DEVMODEType() >>> dm.Position_x=3 >>> dm.Position_x 3 >>> dm.Position_x=long(3) Traceback (most recent call last): File "", line 1, in ? TypeError: bad argument type for built-in operation >>> Here's the relevant code from structmember.c that throws the error: case T_LONG: if (!PyInt_Check(v)) { PyErr_BadArgument(); return -1; } *(long*)addr = PyInt_AsLong(v); break; ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 13:30 Message: Logged In: YES user_id=33168 Can you provide example code that demonstrates what you mean? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470 From noreply at sourceforge.net Thu Aug 24 22:13:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 13:13:33 -0700 Subject: [ python-Bugs-1544762 ] x!=y and [x]==[y] (!) Message-ID: Bugs item #1544762, was opened at 2006-08-22 19:51 Message generated for change (Comment added) made by sgala You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: x!=y and [x]==[y] (!) Initial Comment: Easy to obtain the weird behavior in the summary (in 2.5rc1 and earlier): >>> inf=1e9999 >>> x = y = inf/inf >>> x!=y and [x]==[y] True I propose to fix it by ensuring that lists (and tuples etc) compare their items with exactly the same logic as the == and != operators use. Alex (aleaxit at gmail.com) ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-24 22:13 Message: Logged In: YES user_id=178886 sorry, forget my last comment, as floats are immutable. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-24 13:32 Message: Logged In: YES user_id=178886 comparing tuples by == on elements, instead of "is", would break tuple inmutability and make them unsuitable for keys, BTW. Doing the same with lists would make them behave different to tuples. Liskov and Guttag (Addison Wesley, 2001) book has and interesting discussion on equality in collections, and how java's model has problems (as basically any model with mutable objects that hash on content instead of identity). Python has been doing it right for a lot of time. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-24 13:26 Message: Logged In: YES user_id=178886 This is a consequence of the way list equality is implemented. Counterexample: >>> inf=1e9999 >>> x=inf/inf >>> y=inf/inf >>> x!=y and [x] == [y] False i.e. [x] == [y] iff x is y strings are interned in python (so 'a' is chr(97) returns True), and ints (so 1+1 is 1+1 returns True) but not floats (so inf/inf is inf/inf returns False). Interning floats (or at least "special" numbers, such as nan or inf) could make sense, but I guess this is a RFE, and not a bug, and a different one. ---------------------------------------------------------------------- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-23 10:46 Message: Logged In: YES user_id=1581732 FYI: while not directly related, NaN comparisons keep making trouble. Per bug 1514428, python makes the mistake that inf > Nan should return false, just like Nan < inf. ---------------------------------------------------------------------- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-23 00:49 Message: Logged In: YES user_id=1581732 This appears to be a special oddity of NaN, which is a member of the set of "Things That Do Not Equal Themselves". 1. Are there any more members of this set? 2. Does this mean that any complex data type containing an integer is no a member of this set? 3. Is it odd that, say, a user's StatisticsArray will not equal itself if some statistic in the array is Nan? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 From noreply at sourceforge.net Thu Aug 24 22:57:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 13:57:07 -0700 Subject: [ python-Bugs-1546203 ] bcannon secure branch issues Message-ID: Bugs item #1546203, was opened at 2006-08-24 12:30 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546203&group_id=5470 Please note that this 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: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Brett Cannon (bcannon) Summary: bcannon secure branch issues Initial Comment: Referring to http://svn.python.org/view/python/ branches/bcannon-sandboxing/ securing_python.txt?view=markup but there doesn't seem to be a group/category for feedback on branches. The sys module should *not* be shared between interpreters, even though it is an extension module. (If need be, each sys module can be a proxy that itself imports from the "real" sys.) sys should probably also be filled explicitly on creation, like builtins. (And the same for os, os.path?) Note that this will affect which sys.attributes should be available (perhaps read-only) or hidden by default - - and that should really only be by default. For specific examples: + some programs modify sys.argv to communicated between modules. So long as the initial value of sys.argv is set to something sufficiently discreet, there should be no problem letting them continue to do so. + The current draft hides sys.subversion (revealing unpatched bugs?) but shows sys.version (which reveals the same information, at a coarser grain). + getdefaultencoding may compromise privacy information, particularly for smaller languages. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-08-24 13:57 Message: Logged In: YES user_id=357491 The 'sys' module won' be shared since it is unique per interpreter at the C level. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546203&group_id=5470 From noreply at sourceforge.net Thu Aug 24 23:17:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 14:17:34 -0700 Subject: [ python-Bugs-1546263 ] Segfaults with concurrent sqlite db access and schema change Message-ID: Bugs item #1546263, was opened at 2006-08-24 23:17 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546263&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Gerhard H?ring (ghaering) Assigned to: Gerhard H?ring (ghaering) Summary: Segfaults with concurrent sqlite db access and schema change Initial Comment: This was submitted with the pysqlite tracker: http://initd.org/tracker/pysqlite/ticket/170 It can lead to segfaults in some cases when schema changes happen at critical points in time. It's a very exotic bug that you can only trigger with very unusual database access patterns (running lots and I mean *lots* of database schema changes while other threads/processes access the database). But it's a segfault problem nonetheless and I'd like to fix it before Python 2.5 final. It should not be a showstopper, though. I'm busy right now, but I will attack this problem early next week. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546263&group_id=5470 From noreply at sourceforge.net Fri Aug 25 02:52:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 17:52:26 -0700 Subject: [ python-Bugs-1545696 ] structmember T_LONG won't accept a python long Message-ID: Bugs item #1545696, was opened at 2006-08-23 22:07 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: structmember T_LONG won't accept a python long Initial Comment: An attribute defined as T_LONG throws a vague error when set to a python long, even when the value is within the range of a LONG. TypeError: bad argument type for built-in operation ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 17:52 Message: Logged In: YES user_id=33168 Ugh. This code is lax in checking/conversion. Do you think you could provide a patch? All of the int cases should call PyInt_AsLong() if this call fails (returns -1), then that should be returned from PyMember_SetOne. If it succeeds, there should be a range check that ensures the value is valid. If that fails a warning should be produced. We need to issue a warning rather than an error for backwards compatability (at least for 2.6). The float/double cases can be simplified some by calling PyFloat_AsDouble and doing similar checks as in the int cases. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-08-24 12:56 Message: Logged In: YES user_id=771074 The DEVMODE object from pywintypes has attributes defined as T_LONG via the structmember API. >>> import pywintypes >>> dm=pywintypes.DEVMODEType() >>> dm.Position_x=3 >>> dm.Position_x 3 >>> dm.Position_x=long(3) Traceback (most recent call last): File "", line 1, in ? TypeError: bad argument type for built-in operation >>> Here's the relevant code from structmember.c that throws the error: case T_LONG: if (!PyInt_Check(v)) { PyErr_BadArgument(); return -1; } *(long*)addr = PyInt_AsLong(v); break; ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 11:30 Message: Logged In: YES user_id=33168 Can you provide example code that demonstrates what you mean? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470 From noreply at sourceforge.net Fri Aug 25 07:52:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 24 Aug 2006 22:52:12 -0700 Subject: [ python-Bugs-1546442 ] subprocess.Popen can't read file object as stdin after seek Message-ID: Bugs item #1546442, was opened at 2006-08-25 15: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=1546442&group_id=5470 Please note that this 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: GaryD (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.Popen can't read file object as stdin after seek Initial Comment: When I use an existing file object as stdin for a call to subprocess.Popen, then Popen cannot read the file if I have called seek on it more than once. eg. in the following python code: >>> import subprocess >>> rawfile = file('hello.txt', 'rb') >>> rawfile.readline() 'line 1\n' >>> rawfile.seek(0) >>> rawfile.readline() 'line 1\n' >>> rawfile.seek(0) >>> process_object = subprocess.Popen(["cat"], stdin=rawfile, stdout=subprocess.PIPE, stderr=subprocess.PIPE) process_object.stdout now contains nothing, implying that nothing was on process_object.stdin. Note that this only applies for a non-trivial seek (ie. where the file-pointer actually changes). Calling seek(0) multiple times in a row does not change anything (obviously). I have not investigated whether this reveals a problem with seek not changing the underlying file descriptor, or a problem with Popen not handling the file descriptor properly. I have attached some complete python scripts that demonstrate this problem. One shows cat working after calling seek once, the other shows cat failing after calling seek twice. Python version being used: Python 2.4.2 (#1, Nov 3 2005, 12:41:57) [GCC 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110, ssp-3.4.3.20050110-0, pie-8.7 on linux2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546442&group_id=5470 From noreply at sourceforge.net Fri Aug 25 09:13:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 25 Aug 2006 00:13:36 -0700 Subject: [ python-Bugs-1546442 ] subprocess.Popen can't read file object as stdin after seek Message-ID: Bugs item #1546442, was opened at 2006-08-25 15:52 Message generated for change (Comment added) made by ldeller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546442&group_id=5470 Please note that this 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: GaryD (gazzadee) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.Popen can't read file object as stdin after seek Initial Comment: When I use an existing file object as stdin for a call to subprocess.Popen, then Popen cannot read the file if I have called seek on it more than once. eg. in the following python code: >>> import subprocess >>> rawfile = file('hello.txt', 'rb') >>> rawfile.readline() 'line 1\n' >>> rawfile.seek(0) >>> rawfile.readline() 'line 1\n' >>> rawfile.seek(0) >>> process_object = subprocess.Popen(["cat"], stdin=rawfile, stdout=subprocess.PIPE, stderr=subprocess.PIPE) process_object.stdout now contains nothing, implying that nothing was on process_object.stdin. Note that this only applies for a non-trivial seek (ie. where the file-pointer actually changes). Calling seek(0) multiple times in a row does not change anything (obviously). I have not investigated whether this reveals a problem with seek not changing the underlying file descriptor, or a problem with Popen not handling the file descriptor properly. I have attached some complete python scripts that demonstrate this problem. One shows cat working after calling seek once, the other shows cat failing after calling seek twice. Python version being used: Python 2.4.2 (#1, Nov 3 2005, 12:41:57) [GCC 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110, ssp-3.4.3.20050110-0, pie-8.7 on linux2 ---------------------------------------------------------------------- Comment By: lplatypus (ldeller) Date: 2006-08-25 17:13 Message: Logged In: YES user_id=1534394 I found the cause of this bug: A libc FILE* (used by python file objects) may hold a different file offset than the underlying OS file descriptor. The posix version of Popen._get_handles does not take this into account, resulting in this bug. The following patch against svn trunk fixes the problem. I don't have permission to attach files to this item, so I'll have to paste the patch here: Index: subprocess.py =================================================================== --- subprocess.py (revision 51581) +++ subprocess.py (working copy) @@ -907,6 +907,12 @@ else: # Assuming file-like object p2cread = stdin.fileno() + # OS file descriptor's file offset does not necessarily match + # the file offset in the file-like object, so do an lseek: + try: + os.lseek(p2cread, stdin.tell(), 0) + except OSError: + pass # file descriptor does not support seek/tell if stdout is None: pass @@ -917,6 +923,12 @@ else: # Assuming file-like object c2pwrite = stdout.fileno() + # OS file descriptor's file offset does not necessarily match + # the file offset in the file-like object, so do an lseek: + try: + os.lseek(c2pwrite, stdout.tell(), 0) + except OSError: + pass # file descriptor does not support seek/tell if stderr is None: pass @@ -929,6 +941,12 @@ else: # Assuming file-like object errwrite = stderr.fileno() + # OS file descriptor's file offset does not necessarily match + # the file offset in the file-like object, so do an lseek: + try: + os.lseek(errwrite, stderr.tell(), 0) + except OSError: + pass # file descriptor does not support seek/tell return (p2cread, p2cwrite, c2pread, c2pwrite, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546442&group_id=5470 From noreply at sourceforge.net Fri Aug 25 09:24:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 25 Aug 2006 00:24:55 -0700 Subject: [ python-Bugs-1546442 ] subprocess.Popen can't read file object as stdin after seek Message-ID: Bugs item #1546442, was opened at 2006-08-25 14:52 Message generated for change (Settings changed) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546442&group_id=5470 Please note that this 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: GaryD (gazzadee) >Assigned to: Peter ?strand (astrand) Summary: subprocess.Popen can't read file object as stdin after seek Initial Comment: When I use an existing file object as stdin for a call to subprocess.Popen, then Popen cannot read the file if I have called seek on it more than once. eg. in the following python code: >>> import subprocess >>> rawfile = file('hello.txt', 'rb') >>> rawfile.readline() 'line 1\n' >>> rawfile.seek(0) >>> rawfile.readline() 'line 1\n' >>> rawfile.seek(0) >>> process_object = subprocess.Popen(["cat"], stdin=rawfile, stdout=subprocess.PIPE, stderr=subprocess.PIPE) process_object.stdout now contains nothing, implying that nothing was on process_object.stdin. Note that this only applies for a non-trivial seek (ie. where the file-pointer actually changes). Calling seek(0) multiple times in a row does not change anything (obviously). I have not investigated whether this reveals a problem with seek not changing the underlying file descriptor, or a problem with Popen not handling the file descriptor properly. I have attached some complete python scripts that demonstrate this problem. One shows cat working after calling seek once, the other shows cat failing after calling seek twice. Python version being used: Python 2.4.2 (#1, Nov 3 2005, 12:41:57) [GCC 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110, ssp-3.4.3.20050110-0, pie-8.7 on linux2 ---------------------------------------------------------------------- Comment By: lplatypus (ldeller) Date: 2006-08-25 16:13 Message: Logged In: YES user_id=1534394 I found the cause of this bug: A libc FILE* (used by python file objects) may hold a different file offset than the underlying OS file descriptor. The posix version of Popen._get_handles does not take this into account, resulting in this bug. The following patch against svn trunk fixes the problem. I don't have permission to attach files to this item, so I'll have to paste the patch here: Index: subprocess.py =================================================================== --- subprocess.py (revision 51581) +++ subprocess.py (working copy) @@ -907,6 +907,12 @@ else: # Assuming file-like object p2cread = stdin.fileno() + # OS file descriptor's file offset does not necessarily match + # the file offset in the file-like object, so do an lseek: + try: + os.lseek(p2cread, stdin.tell(), 0) + except OSError: + pass # file descriptor does not support seek/tell if stdout is None: pass @@ -917,6 +923,12 @@ else: # Assuming file-like object c2pwrite = stdout.fileno() + # OS file descriptor's file offset does not necessarily match + # the file offset in the file-like object, so do an lseek: + try: + os.lseek(c2pwrite, stdout.tell(), 0) + except OSError: + pass # file descriptor does not support seek/tell if stderr is None: pass @@ -929,6 +941,12 @@ else: # Assuming file-like object errwrite = stderr.fileno() + # OS file descriptor's file offset does not necessarily match + # the file offset in the file-like object, so do an lseek: + try: + os.lseek(errwrite, stderr.tell(), 0) + except OSError: + pass # file descriptor does not support seek/tell return (p2cread, p2cwrite, c2pread, c2pwrite, ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546442&group_id=5470 From noreply at sourceforge.net Fri Aug 25 13:39:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 25 Aug 2006 04:39:11 -0700 Subject: [ python-Bugs-1546585 ] String methods don't support explicit None arguments Message-ID: Bugs item #1546585, was opened at 2006-08-25 21: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=1546585&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 7 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: String methods don't support explicit None arguments Initial Comment: Unlike normal slicing, string methods do not currently support passing an explicit None argument (you either have to omit the arguments, or pass an actual integer or object with an __index__ method). This was the case in previous Python versions, so no existing code is going to break. However these methods issue the same TypeError message as normal slicing which now explicitly lists None as an acceptable value, which is confusing as all heck when the call that breaks is "s.index(sub, start, stop)"m and printing out start and stop shows them both to be None. Given that the string docs say things like (from str.count) "Optional arguments start and end are interpreted as in slice notation", I think this should be fixed (which is why I put it on the bug tracker for 2.5, not the RFE one for 2.6). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546585&group_id=5470 From noreply at sourceforge.net Fri Aug 25 14:04:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 25 Aug 2006 05:04:21 -0700 Subject: [ python-Bugs-1546585 ] String methods don't support explicit None arguments Message-ID: Bugs item #1546585, was opened at 2006-08-25 21:39 Message generated for change (Settings changed) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546585&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open >Resolution: Later Priority: 7 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: String methods don't support explicit None arguments Initial Comment: Unlike normal slicing, string methods do not currently support passing an explicit None argument (you either have to omit the arguments, or pass an actual integer or object with an __index__ method). This was the case in previous Python versions, so no existing code is going to break. However these methods issue the same TypeError message as normal slicing which now explicitly lists None as an acceptable value, which is confusing as all heck when the call that breaks is "s.index(sub, start, stop)"m and printing out start and stop shows them both to be None. Given that the string docs say things like (from str.count) "Optional arguments start and end are interpreted as in slice notation", I think this should be fixed (which is why I put it on the bug tracker for 2.5, not the RFE one for 2.6). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546585&group_id=5470 From noreply at sourceforge.net Fri Aug 25 15:04:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 25 Aug 2006 06:04:08 -0700 Subject: [ python-Bugs-1546628 ] urlparse.urljoin odd behaviour Message-ID: Bugs item #1546628, was opened at 2006-08-25 10:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546628&group_id=5470 Please note that this 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: Andres Riancho (andresriancho) Assigned to: Nobody/Anonymous (nobody) Summary: urlparse.urljoin odd behaviour Initial Comment: Hi ! I think i have found a bug on the urljoin function of the urlparse module. I'm using Python 2.4.3 (#2, Apr 27 2006, 14:43:58), [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 . Here is a demo of the bug : >>> import urlparse >>>urlparse.urljoin('http://www.f00.com/','//a') 'http://a' >>> urlparse.urljoin('http://www.f00.com/','https://0000/somethingIsWrong') 'https://0000/somethingIsWrong' >>> urlparse.urljoin('http://www.f00.com/','https://0000/somethingIsWrong') 'https://0000/somethingIsWrong' >>> urlparse.urljoin('http://www.f00.com/','file:///etc/passwd') 'file:///etc/passwd' The result for the first call to urljoin should be either 'http://www.f00.com/a' or 'http://www.f00.com//a'. The result to the second and third call to urljoin should be 'http://www.f00.com/', or maybe an exception ? Please correct me if i'm wrong and this is some kind of feature or the bug was already reported. This bug can result in a security vuln, take this code as an example: // viewImage.py // import htmlTools # Some fake module, just for the example import urlparse # module with bug. htmlTools.startHtml() # print params = htmlTools.getParams() # get the query string parameters htmlTools.printToHtml( '' ) htmlTools.endHtml() # print // viewImage.py // The code should generate an html that shows an image from the site http://myWebsite/, but with the urljoin bug, the image source can be manipulated and result in a completely different html. Cheers, Andres Riancho ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546628&group_id=5470 From noreply at sourceforge.net Sat Aug 26 22:25:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 26 Aug 2006 13:25:46 -0700 Subject: [ python-Bugs-1545668 ] gcc trunk (4.2) exposes a signed integer overflows Message-ID: Bugs item #1545668, was opened at 2006-08-23 23:14 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 Please note that this 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: Jack Howarth (jwhowarth) >Assigned to: Nobody/Anonymous (nobody) Summary: gcc trunk (4.2) exposes a signed integer overflows Initial Comment: While building python 2.4.3 with the current gcc trunk (soon to be 4.2), I uncovered a signed integer overflows bug in Python with the help of one of the gcc developers. The bug I observed is documented in this gcc mailing list message... http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html The gcc developer comments about its origin are in the messages... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00442.html which in short says... It *is* a bug in python, here is the proof: https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/ Objects/intobject.c?revision=25647&view=markup Function * i_divmod*(*register* *long* x, *register* *long* y, the following lines: / /* (-sys.maxint-1)/-1 is the only overflow case. *// *if* (y == -1 && x < 0 && x == -x) *return* DIVMOD_OVERFLOW; If overflow is barred then x==-x may happen only when x==0. This conflicts with x<0, which means that the compiler may assume that x<0 && x==-x always yields false. This may allow the compiler to eliminate the whole if statement. Hence, clearly python is at fault. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-08-26 16:25 Message: Logged In: YES user_id=31435 Looks like the same deal as bug 1521947 (which was about similar code in PyOS_strtol()). ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 11:22 Message: Logged In: YES user_id=403009 Everyone involved in reviewing this patch should definitely read the following sequence of gcc mailing list messages which show the process by which this patch was arrived at... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html http://gcc.gnu.org/ml/gcc/2006-08/msg00437.html http://gcc.gnu.org/ml/gcc/2006-08/msg00443.html http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html http://gcc.gnu.org/ml/gcc/2006-08/msg00447.html http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html So we have had lots of gcc developer eyes on this problem and they all agree on the flaw and the fix as posted. It's unfortunate that I had to abuse their mailing list to get this addressed before python 2.5 gets released. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 11:00 Message: Logged In: YES user_id=33168 I grepped for ' == .*-[^1>]' and ' != .*-[^1>]' and didn't spot any other occurrences. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2006-08-24 10:54 Message: Logged In: YES user_id=43607 Just a comment, I'm not claiming this bug. The test (x < 0 && x == -x) tests whether x is equal to the smallest negative number. If x is equal to -2147483648, then -x is also equal to -2147483648 due to overflow. What does this version of gcc do with this code when x = -2147483648? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 10:54 Message: Logged In: YES user_id=33168 Assigning to Tim, he likes these problems. :-) He recently fixed a similar problem in another piece of code. I'm going to try to grep and see if I can find more occurrences of this. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 10:37 Message: Logged In: YES user_id=45365 Hmm... intobject.c doesn't really have a "champion"... Neal, I'm assigning this to you purely on the ground that you're the last person to have edited this file. Feel free to pass on (but not back:-). ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 07:22 Message: Logged In: YES user_id=403009 The was a few other comments from the gcc developers on the proposed fix... http://gcc.gnu.org/ml/gcc/2006-08/msg00448.html http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html ...so that since x is a long the more correct fix is... --- Python-2.4.3/Objects/intobject.c.org 2006-08-24 07:06:51.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-24 07:08:06.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned long)x) == -(unsigned long)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; I have tested this form of the patch and it works as well. My main concern is that we get this fix in python 2.5 before release. Jack, could you reassign this to the person you think might be most appropriate out of the list of python developers? I really should be a pretty simple review for the patch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 05:14 Message: Logged In: YES user_id=45365 I don't think this is a mac-specific bug, and I'm also not really the right person to look into this... ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 00:13 Message: Logged In: YES user_id=403009 As suggested by another gcc developer in... http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html ...the following patch eliminates the error when python is built with gcc trunk... --- Python-2.4.3/Objects/intobject.c.org 2006-08-23 23:49:33.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-23 23:52:01.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned)x) == -(unsigned)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; This change allows python to completely pass its make check now when built with gcc trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 From noreply at sourceforge.net Sat Aug 26 22:33:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 26 Aug 2006 13:33:15 -0700 Subject: [ python-Bugs-1545668 ] gcc trunk (4.2) exposes a signed integer overflows Message-ID: Bugs item #1545668, was opened at 2006-08-23 23:14 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 Please note that this 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: 8 Submitted By: Jack Howarth (jwhowarth) Assigned to: Nobody/Anonymous (nobody) Summary: gcc trunk (4.2) exposes a signed integer overflows Initial Comment: While building python 2.4.3 with the current gcc trunk (soon to be 4.2), I uncovered a signed integer overflows bug in Python with the help of one of the gcc developers. The bug I observed is documented in this gcc mailing list message... http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html The gcc developer comments about its origin are in the messages... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00442.html which in short says... It *is* a bug in python, here is the proof: https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/ Objects/intobject.c?revision=25647&view=markup Function * i_divmod*(*register* *long* x, *register* *long* y, the following lines: / /* (-sys.maxint-1)/-1 is the only overflow case. *// *if* (y == -1 && x < 0 && x == -x) *return* DIVMOD_OVERFLOW; If overflow is barred then x==-x may happen only when x==0. This conflicts with x<0, which means that the compiler may assume that x<0 && x==-x always yields false. This may allow the compiler to eliminate the whole if statement. Hence, clearly python is at fault. ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-08-26 16:33 Message: Logged In: YES user_id=31435 Boosted priority to 8 since it was brought up on python-dev as a suggested 2.5 release-blocker. The patch in the first comment looks fine, if a release manager wants to apply it. Python 2.4 surely has the same "issue". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-08-26 16:25 Message: Logged In: YES user_id=31435 Looks like the same deal as bug 1521947 (which was about similar code in PyOS_strtol()). ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 11:22 Message: Logged In: YES user_id=403009 Everyone involved in reviewing this patch should definitely read the following sequence of gcc mailing list messages which show the process by which this patch was arrived at... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html http://gcc.gnu.org/ml/gcc/2006-08/msg00437.html http://gcc.gnu.org/ml/gcc/2006-08/msg00443.html http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html http://gcc.gnu.org/ml/gcc/2006-08/msg00447.html http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html So we have had lots of gcc developer eyes on this problem and they all agree on the flaw and the fix as posted. It's unfortunate that I had to abuse their mailing list to get this addressed before python 2.5 gets released. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 11:00 Message: Logged In: YES user_id=33168 I grepped for ' == .*-[^1>]' and ' != .*-[^1>]' and didn't spot any other occurrences. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2006-08-24 10:54 Message: Logged In: YES user_id=43607 Just a comment, I'm not claiming this bug. The test (x < 0 && x == -x) tests whether x is equal to the smallest negative number. If x is equal to -2147483648, then -x is also equal to -2147483648 due to overflow. What does this version of gcc do with this code when x = -2147483648? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 10:54 Message: Logged In: YES user_id=33168 Assigning to Tim, he likes these problems. :-) He recently fixed a similar problem in another piece of code. I'm going to try to grep and see if I can find more occurrences of this. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 10:37 Message: Logged In: YES user_id=45365 Hmm... intobject.c doesn't really have a "champion"... Neal, I'm assigning this to you purely on the ground that you're the last person to have edited this file. Feel free to pass on (but not back:-). ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 07:22 Message: Logged In: YES user_id=403009 The was a few other comments from the gcc developers on the proposed fix... http://gcc.gnu.org/ml/gcc/2006-08/msg00448.html http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html ...so that since x is a long the more correct fix is... --- Python-2.4.3/Objects/intobject.c.org 2006-08-24 07:06:51.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-24 07:08:06.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned long)x) == -(unsigned long)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; I have tested this form of the patch and it works as well. My main concern is that we get this fix in python 2.5 before release. Jack, could you reassign this to the person you think might be most appropriate out of the list of python developers? I really should be a pretty simple review for the patch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 05:14 Message: Logged In: YES user_id=45365 I don't think this is a mac-specific bug, and I'm also not really the right person to look into this... ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 00:13 Message: Logged In: YES user_id=403009 As suggested by another gcc developer in... http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html ...the following patch eliminates the error when python is built with gcc trunk... --- Python-2.4.3/Objects/intobject.c.org 2006-08-23 23:49:33.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-23 23:52:01.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned)x) == -(unsigned)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; This change allows python to completely pass its make check now when built with gcc trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 From noreply at sourceforge.net Sat Aug 26 23:36:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 26 Aug 2006 14:36:33 -0700 Subject: [ python-Feature Requests-1547300 ] Wireless on Python Message-ID: Feature Requests item #1547300, was opened at 2006-08-27 00:36 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=1547300&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Submitted By: Ahmet Bi?kinler (ahmetbiskinler) Assigned to: Nobody/Anonymous (nobody) Summary: Wireless on Python Initial Comment: It would be very nice if Python had a Wireless Module that works on all platforms. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1547300&group_id=5470 From noreply at sourceforge.net Sun Aug 27 01:24:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 26 Aug 2006 16:24:32 -0700 Subject: [ python-Bugs-1545668 ] gcc trunk (4.2) exposes a signed integer overflows Message-ID: Bugs item #1545668, was opened at 2006-08-24 04:14 Message generated for change (Comment added) made by dhopwood You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 Please note that this 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: 8 Submitted By: Jack Howarth (jwhowarth) Assigned to: Nobody/Anonymous (nobody) Summary: gcc trunk (4.2) exposes a signed integer overflows Initial Comment: While building python 2.4.3 with the current gcc trunk (soon to be 4.2), I uncovered a signed integer overflows bug in Python with the help of one of the gcc developers. The bug I observed is documented in this gcc mailing list message... http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html The gcc developer comments about its origin are in the messages... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00442.html which in short says... It *is* a bug in python, here is the proof: https://codespeak.net/viewvc/vendor/cpython/Python-r243/dist/src/ Objects/intobject.c?revision=25647&view=markup Function * i_divmod*(*register* *long* x, *register* *long* y, the following lines: / /* (-sys.maxint-1)/-1 is the only overflow case. *// *if* (y == -1 && x < 0 && x == -x) *return* DIVMOD_OVERFLOW; If overflow is barred then x==-x may happen only when x==0. This conflicts with x<0, which means that the compiler may assume that x<0 && x==-x always yields false. This may allow the compiler to eliminate the whole if statement. Hence, clearly python is at fault. ---------------------------------------------------------------------- Comment By: David Hopwood (dhopwood) Date: 2006-08-27 00:24 Message: Logged In: YES user_id=634468 The correct patch is the one that uses if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x) The one that uses (unsigned int)x will break some 64-bit platforms where int != long. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-08-26 21:33 Message: Logged In: YES user_id=31435 Boosted priority to 8 since it was brought up on python-dev as a suggested 2.5 release-blocker. The patch in the first comment looks fine, if a release manager wants to apply it. Python 2.4 surely has the same "issue". ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-08-26 21:25 Message: Logged In: YES user_id=31435 Looks like the same deal as bug 1521947 (which was about similar code in PyOS_strtol()). ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 16:22 Message: Logged In: YES user_id=403009 Everyone involved in reviewing this patch should definitely read the following sequence of gcc mailing list messages which show the process by which this patch was arrived at... http://gcc.gnu.org/ml/gcc/2006-08/msg00434.html http://gcc.gnu.org/ml/gcc/2006-08/msg00436.html http://gcc.gnu.org/ml/gcc/2006-08/msg00437.html http://gcc.gnu.org/ml/gcc/2006-08/msg00443.html http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html http://gcc.gnu.org/ml/gcc/2006-08/msg00447.html http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html So we have had lots of gcc developer eyes on this problem and they all agree on the flaw and the fix as posted. It's unfortunate that I had to abuse their mailing list to get this addressed before python 2.5 gets released. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 16:00 Message: Logged In: YES user_id=33168 I grepped for ' == .*-[^1>]' and ' != .*-[^1>]' and didn't spot any other occurrences. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2006-08-24 15:54 Message: Logged In: YES user_id=43607 Just a comment, I'm not claiming this bug. The test (x < 0 && x == -x) tests whether x is equal to the smallest negative number. If x is equal to -2147483648, then -x is also equal to -2147483648 due to overflow. What does this version of gcc do with this code when x = -2147483648? ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 15:54 Message: Logged In: YES user_id=33168 Assigning to Tim, he likes these problems. :-) He recently fixed a similar problem in another piece of code. I'm going to try to grep and see if I can find more occurrences of this. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 15:37 Message: Logged In: YES user_id=45365 Hmm... intobject.c doesn't really have a "champion"... Neal, I'm assigning this to you purely on the ground that you're the last person to have edited this file. Feel free to pass on (but not back:-). ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 12:22 Message: Logged In: YES user_id=403009 The was a few other comments from the gcc developers on the proposed fix... http://gcc.gnu.org/ml/gcc/2006-08/msg00448.html http://gcc.gnu.org/ml/gcc/2006-08/msg00449.html ...so that since x is a long the more correct fix is... --- Python-2.4.3/Objects/intobject.c.org 2006-08-24 07:06:51.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-24 07:08:06.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned long)x) == -(unsigned long)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; I have tested this form of the patch and it works as well. My main concern is that we get this fix in python 2.5 before release. Jack, could you reassign this to the person you think might be most appropriate out of the list of python developers? I really should be a pretty simple review for the patch. ---------------------------------------------------------------------- Comment By: Jack Jansen (jackjansen) Date: 2006-08-24 10:14 Message: Logged In: YES user_id=45365 I don't think this is a mac-specific bug, and I'm also not really the right person to look into this... ---------------------------------------------------------------------- Comment By: Jack Howarth (jwhowarth) Date: 2006-08-24 05:13 Message: Logged In: YES user_id=403009 As suggested by another gcc developer in... http://gcc.gnu.org/ml/gcc/2006-08/msg00446.html ...the following patch eliminates the error when python is built with gcc trunk... --- Python-2.4.3/Objects/intobject.c.org 2006-08-23 23:49:33.000000000 -0400 +++ Python-2.4.3/Objects/intobject.c 2006-08-23 23:52:01.000000000 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the only overflow case. */ - if (y == -1 && x < 0 && x == -x) + if (y == -1 && x < 0 && ((unsigned)x) == -(unsigned)x) return DIVMOD_OVERFLOW; xdivy = x / y; xmody = x - xdivy * y; This change allows python to completely pass its make check now when built with gcc trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545668&group_id=5470 From noreply at sourceforge.net Sun Aug 27 12:09:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Aug 2006 03:09:50 -0700 Subject: [ python-Bugs-1531963 ] SocketServer.TCPServer returns different ports Message-ID: Bugs item #1531963, was opened at 2006-07-31 19:58 Message generated for change (Settings changed) made by hakker_de You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531963&group_id=5470 Please note that this 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: Fixed Priority: 5 Submitted By: hakker.de (hakker_de) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer.TCPServer returns different ports Initial Comment: Providing 0 as a port in __init__ of SocketServer.TCPServer leads to different values for port in server_address and socket.getsockname(). Example: import SocketServer s = SocketServer.TCPServer(("0.0.0.0", 0), Handler) s.server_address -> ('0.0.0.0', 0) s.socket.getsockname() -> ('0.0.0.0', 39129) s.server_address should also contain 39129 as the port number for the free port found. ---------------------------------------------------------------------- Comment By: Damon Kohler (damonkohler) Date: 2006-08-23 01:36 Message: Logged In: YES user_id=705317 Patch 1545011 is a proposed fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531963&group_id=5470 From noreply at sourceforge.net Sun Aug 27 19:37:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Aug 2006 10:37:01 -0700 Subject: [ python-Bugs-1543801 ] md5 sums are different between Solaris and Windows XP SP1 Message-ID: Bugs item #1543801, was opened at 2006-08-21 01:21 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543801&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.3 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Stefan Sonnenberg (sunmountain) Assigned to: Nobody/Anonymous (nobody) Summary: md5 sums are different between Solaris and Windows XP SP1 Initial Comment: The following program produces different md5 sums under Solaris and Windows XP, but sums are equal under the same platform. #!/opt/ASpy23/bin/python import sys import md5 import getopt import os import re try: opts,args = getopt.getopt(sys.argv[1:],'c:f:h') except getopt.GetoptError,e: print 'Parsing command line arguments failed. (%s)' % str(e) sys.exit(1) md5file = None fname = None for o,a in opts: if o in '-c': if fname is not None: print '-c and -f are mutually exclusive' sys.exit(1) md5file = a if o in '-f': if md5file is not None: print '-c and -f are mutually exclusive' sys.exit(1) fname = a if o in '-h': print 'Usage: md5 filename. (%s)' % str(e) sys.exit(1) if md5file is not None and os.path.isfile(md5file): try: lines = open(md5file,'r').readlines() except IOError,e: print 'Could not read MD5 sum file %s. (%s)' % (md5file,str(e)) sys.exit(1) for line in lines: line = line[:-1] try: res = re.compile('MD5[ |\t]+\((.+)\)[ |\t]+?\=[ |\t]+(.+)').findall(line)[0] except Exception,e: print 'Could not parse line. (%s)' % str(e) sys.exit(1) if os.path.isfile(res[0]): try: f = open(res[0],'r') except IOError,e: print 'Could not open file %s. (%s)' % (res[0],str(e)) sys.exit(1) sum = md5.new() try: sum.update(f.read()) except Exception,e: print 'Could not update MD5 sum. (%s)' % str(e) sys.exit(1) #print sum.hexdigest(),res[1][2:],res[0],line if sum.hexdigest() == res[1][2:]: print 'MD5 sum of file %s is OK' % res[0] else: print 'MD5 sum of file %s DIFFERS' % res[0] f.close() sum = None sys.exit(0) sum = md5.new() try: f = open(fname,'r') except IOError,e: print 'Could not open %s. (%s)' % ( fname,str(e) ) try: sum.update(f.read()) except Exception,e: print 'Could not update md5 sum. (%s)' % str(e) print 'MD5 (%s) = 0x%s' % (fname,sum.hexdigest()) f.close() Python version Solaris: Python 2.3.5 (#1, Feb 9 2005, 14:45:39) [C] on sunos5 Python version Windows XP: Python 2.3.5 (#62, Feb 9 2005, 16:17:08) [MSC v.1200 32 bit (Intel)] on win32 ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-08-27 10:37 Message: Logged In: YES user_id=341410 Open your files with the 'rb' flag and the md5 sums will be indentical. ---------------------------------------------------------------------- Comment By: Stefan Sonnenberg (sunmountain) Date: 2006-08-21 02:06 Message: Logged In: YES user_id=1575341 I double checked the behaviour. With Python the md5 sums differ between Solaris and Windows. Using external tools for generating md5 sums, these are always equal, under both systems, as it should be with md5. I did not try other python versions. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-21 02:06 Message: Logged In: YES user_id=849994 You're opening files in text mode, which is likely to return different file contents on Windows and Unix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543801&group_id=5470 From noreply at sourceforge.net Sun Aug 27 19:44:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Aug 2006 10:44:43 -0700 Subject: [ python-Bugs-1542407 ] httplib reads one byte per system call Message-ID: Bugs item #1542407, was opened at 2006-08-17 21:33 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542407&group_id=5470 Please note that this 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: Zoyd Wheeler (zoyd2k) Assigned to: Nobody/Anonymous (nobody) Summary: httplib reads one byte per system call Initial Comment: The HTTPResponse class in httplib.py contains the following line in its __init__ method: self.fp = sock.makefile('rb', 0) The zero in that second (bufsize) argument overrides the default behavior of the socket filedescriptor in its readline() method, which is to read in a buffer's worth of data from the socket at a time and only hit the socket again if the buffer runs dry. When bufsize is set to zero, the filedescriptor sets its internal buffer size to one. As a result, readline() makes a system call for every byte of data consumed. Since httplib uses readline to obtain the http header, that's an awful lot of system calls. We noticed this when trying to build a fairly aggressive application on top of xmlrpclib (which relies on httplib); we saw tons of system call activity. There is no comment near this line of code to indicate whether this behavior is intended or not. If it is not intended, the patch is to simply remove the second argument and rely on the default (or allow the caller to specify a buffer size). In case reading a byte at a time is actually intended, we have a simple work-around for those who care to use it. In the python code that uses httplib, add the following: import httplib ... class HTTPResponse(httplib.HTTPResponse): def __init__(self, sock, **kw): httplib.HTTPResponse.__init__(self, sock, **kw) self.fp = sock.makefile('rb') httplib.HTTPConnection.response_class = HTTPResponse ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-08-27 10:44 Message: Logged In: YES user_id=341410 Because the socket is in blocking mode, performing self.fp.read(x) with an x > 1 will generally block until it has read x bytes or the other end disconnects. As such, I believe it is intended behavior. For your own application, you could perhaps write a response class that uses non-blocking sockets to handle readline, switching back to blocking sockets after header reading is over. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542407&group_id=5470 From noreply at sourceforge.net Mon Aug 28 04:23:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Aug 2006 19:23:56 -0700 Subject: [ python-Bugs-1545696 ] structmember T_LONG won't accept a python long Message-ID: Bugs item #1545696, was opened at 2006-08-24 00:07 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: structmember T_LONG won't accept a python long Initial Comment: An attribute defined as T_LONG throws a vague error when set to a python long, even when the value is within the range of a LONG. TypeError: bad argument type for built-in operation ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-08-27 21:23 Message: Logged In: YES user_id=771074 In the process of creating a patch for this, I came across some more 'ugh'-liness. T_UINT's are returned via PyInt_FromLong, so you actually get back a negative value for large numbers. Changing it to use PyLong_FromUnsignedLong will break backward compatibility, but this is so wrong I can't possibly see keeping it. Your call. (plus it makes it impossible to test T_UINT with values larger than INT_MAX) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 19:52 Message: Logged In: YES user_id=33168 Ugh. This code is lax in checking/conversion. Do you think you could provide a patch? All of the int cases should call PyInt_AsLong() if this call fails (returns -1), then that should be returned from PyMember_SetOne. If it succeeds, there should be a range check that ensures the value is valid. If that fails a warning should be produced. We need to issue a warning rather than an error for backwards compatability (at least for 2.6). The float/double cases can be simplified some by calling PyFloat_AsDouble and doing similar checks as in the int cases. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-08-24 14:56 Message: Logged In: YES user_id=771074 The DEVMODE object from pywintypes has attributes defined as T_LONG via the structmember API. >>> import pywintypes >>> dm=pywintypes.DEVMODEType() >>> dm.Position_x=3 >>> dm.Position_x 3 >>> dm.Position_x=long(3) Traceback (most recent call last): File "", line 1, in ? TypeError: bad argument type for built-in operation >>> Here's the relevant code from structmember.c that throws the error: case T_LONG: if (!PyInt_Check(v)) { PyErr_BadArgument(); return -1; } *(long*)addr = PyInt_AsLong(v); break; ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 13:30 Message: Logged In: YES user_id=33168 Can you provide example code that demonstrates what you mean? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470 From noreply at sourceforge.net Mon Aug 28 15:10:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 06:10:09 -0700 Subject: [ python-Bugs-1544762 ] x!=y and [x]==[y] (!) Message-ID: Bugs item #1544762, was opened at 2006-08-22 12:51 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open >Resolution: Invalid Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: x!=y and [x]==[y] (!) Initial Comment: Easy to obtain the weird behavior in the summary (in 2.5rc1 and earlier): >>> inf=1e9999 >>> x = y = inf/inf >>> x!=y and [x]==[y] True I propose to fix it by ensuring that lists (and tuples etc) compare their items with exactly the same logic as the == and != operators use. Alex (aleaxit at gmail.com) ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-28 08:10 Message: Logged In: YES user_id=80475 IMO, this should not be changed. Through-out Python (not just for lists and tuples), internal routines assume that identity implies equality. All your example shows is that the oddball NaN is in-fact odd. IMO, the result weird, but correct. The x!=y result is correct because that is a property of NaNs and the [x]==[y] result is correct because the two lists have identical content. You would get the expected result when the content is not identical: >>> inf=1e9999 >>> x = inf/inf >>> y = inf/inf >>> x != y True >>> [x] == [y] I do not want the rest of Python mucked-up just because NaNs are designed to not follow the most basic definitions of equality (i.e. a relation is an equality relative if and only if it is reflexsive, symmetric, and transitive). Closing as not-a-bug. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-24 15:13 Message: Logged In: YES user_id=178886 sorry, forget my last comment, as floats are immutable. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-24 06:32 Message: Logged In: YES user_id=178886 comparing tuples by == on elements, instead of "is", would break tuple inmutability and make them unsuitable for keys, BTW. Doing the same with lists would make them behave different to tuples. Liskov and Guttag (Addison Wesley, 2001) book has and interesting discussion on equality in collections, and how java's model has problems (as basically any model with mutable objects that hash on content instead of identity). Python has been doing it right for a lot of time. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-24 06:26 Message: Logged In: YES user_id=178886 This is a consequence of the way list equality is implemented. Counterexample: >>> inf=1e9999 >>> x=inf/inf >>> y=inf/inf >>> x!=y and [x] == [y] False i.e. [x] == [y] iff x is y strings are interned in python (so 'a' is chr(97) returns True), and ints (so 1+1 is 1+1 returns True) but not floats (so inf/inf is inf/inf returns False). Interning floats (or at least "special" numbers, such as nan or inf) could make sense, but I guess this is a RFE, and not a bug, and a different one. ---------------------------------------------------------------------- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-23 03:46 Message: Logged In: YES user_id=1581732 FYI: while not directly related, NaN comparisons keep making trouble. Per bug 1514428, python makes the mistake that inf > Nan should return false, just like Nan < inf. ---------------------------------------------------------------------- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-22 17:49 Message: Logged In: YES user_id=1581732 This appears to be a special oddity of NaN, which is a member of the set of "Things That Do Not Equal Themselves". 1. Are there any more members of this set? 2. Does this mean that any complex data type containing an integer is no a member of this set? 3. Is it odd that, say, a user's StatisticsArray will not equal itself if some statistic in the array is Nan? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 From noreply at sourceforge.net Mon Aug 28 15:32:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 06:32:40 -0700 Subject: [ python-Bugs-1545837 ] array.array borks on deepcopy Message-ID: Bugs item #1545837, was opened at 2006-08-24 04:49 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&group_id=5470 Please note that this 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: Later Priority: 7 Submitted By: V?clav Haisman (wilx) >Assigned to: Anthony Baxter (anthonybaxter) Summary: array.array borks on deepcopy Initial Comment: Hi, I think there is a bug arraymodule.c this line: {"__deepcopy__",(PyCFunction)array_copy, METH_NOARGS, copy_doc}, should probably have METH_O instead of METH_NOARGS there, since according to docs and the prototype of the array_copy() function there is one parameter. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-28 08:32 Message: Logged In: YES user_id=80475 Should this be fixed in the release candidate? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-08-24 13:50 Message: Logged In: YES user_id=34209 Thanks! Fixed in the trunk (which is 2.6-to-be) revision 51565, and it will also be fixed for Python 2.4.4 and 2.5.1. It's unfortunately just a bit too late for 2.5.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&group_id=5470 From noreply at sourceforge.net Mon Aug 28 15:34:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 06:34:47 -0700 Subject: [ python-Bugs-1544762 ] x!=y and [x]==[y] (!) Message-ID: Bugs item #1544762, was opened at 2006-08-22 12:51 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Alex Martelli (aleax) Assigned to: Nobody/Anonymous (nobody) Summary: x!=y and [x]==[y] (!) Initial Comment: Easy to obtain the weird behavior in the summary (in 2.5rc1 and earlier): >>> inf=1e9999 >>> x = y = inf/inf >>> x!=y and [x]==[y] True I propose to fix it by ensuring that lists (and tuples etc) compare their items with exactly the same logic as the == and != operators use. Alex (aleaxit at gmail.com) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-28 08:10 Message: Logged In: YES user_id=80475 IMO, this should not be changed. Through-out Python (not just for lists and tuples), internal routines assume that identity implies equality. All your example shows is that the oddball NaN is in-fact odd. IMO, the result weird, but correct. The x!=y result is correct because that is a property of NaNs and the [x]==[y] result is correct because the two lists have identical content. You would get the expected result when the content is not identical: >>> inf=1e9999 >>> x = inf/inf >>> y = inf/inf >>> x != y True >>> [x] == [y] I do not want the rest of Python mucked-up just because NaNs are designed to not follow the most basic definitions of equality (i.e. a relation is an equality relative if and only if it is reflexsive, symmetric, and transitive). Closing as not-a-bug. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-24 15:13 Message: Logged In: YES user_id=178886 sorry, forget my last comment, as floats are immutable. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-24 06:32 Message: Logged In: YES user_id=178886 comparing tuples by == on elements, instead of "is", would break tuple inmutability and make them unsuitable for keys, BTW. Doing the same with lists would make them behave different to tuples. Liskov and Guttag (Addison Wesley, 2001) book has and interesting discussion on equality in collections, and how java's model has problems (as basically any model with mutable objects that hash on content instead of identity). Python has been doing it right for a lot of time. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-24 06:26 Message: Logged In: YES user_id=178886 This is a consequence of the way list equality is implemented. Counterexample: >>> inf=1e9999 >>> x=inf/inf >>> y=inf/inf >>> x!=y and [x] == [y] False i.e. [x] == [y] iff x is y strings are interned in python (so 'a' is chr(97) returns True), and ints (so 1+1 is 1+1 returns True) but not floats (so inf/inf is inf/inf returns False). Interning floats (or at least "special" numbers, such as nan or inf) could make sense, but I guess this is a RFE, and not a bug, and a different one. ---------------------------------------------------------------------- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-23 03:46 Message: Logged In: YES user_id=1581732 FYI: while not directly related, NaN comparisons keep making trouble. Per bug 1514428, python makes the mistake that inf > Nan should return false, just like Nan < inf. ---------------------------------------------------------------------- Comment By: CharlesMerriam (charlesmerriam) Date: 2006-08-22 17:49 Message: Logged In: YES user_id=1581732 This appears to be a special oddity of NaN, which is a member of the set of "Things That Do Not Equal Themselves". 1. Are there any more members of this set? 2. Does this mean that any complex data type containing an integer is no a member of this set? 3. Is it odd that, say, a user's StatisticsArray will not equal itself if some statistic in the array is Nan? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1544762&group_id=5470 From noreply at sourceforge.net Mon Aug 28 15:57:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 06:57:08 -0700 Subject: [ python-Bugs-1528802 ] Turkish Character Message-ID: Bugs item #1528802, was opened at 2006-07-26 10:05 Message generated for change (Comment added) made by ahmetbiskinler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 Please note that this 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.5 Status: Open Resolution: None >Priority: 6 Submitted By: Ahmet Bi?kinler (ahmetbiskinler) Assigned to: M.-A. Lemburg (lemburg) Summary: Turkish Character Initial Comment: >>> print "May?s".upper() >>> MAY?S >>> import locale >>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254') >>> print "May?s".upper() >>> MAY?S >>> print "???i???".upper() >>> ???I??? MAY?S should be MAYIS ???I??? should be ??????I but >>> "May?s".upper() >>> "MAYIS" is right ---------------------------------------------------------------------- >Comment By: Ahmet Bi?kinler (ahmetbiskinler) Date: 2006-08-28 16:57 Message: Logged In: YES user_id=1481281 As you saw in the picture the IDLE does its work. Its is the one who is working right. The python interpreter(C:\Python25\Python.exe) has the problem with it. Does the interpreter generate bug reports if there is no crashing or else... And I don't know how to file an IDLE bug report from the interpreter(C:\Python25\Python.exe). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-21 13:01 Message: Logged In: YES user_id=38388 Could we please get some things straight first: 1. if you're working with IDLE and it doesn't do what you expect it to, please file an IDLE bug report, not a Python one; the same it true for any other Python IDE you are using 2. string's .lower() and .upper() method rely 100% on the platform's C lib implementation of these functions; there's nothing Python can do about bugs in these implementations 3. if you want reproducable behavior across platforms, please always use Unicode, *not* 8-bit strings, for text data. I see that #1 has already been done, so the IDLE specific discussion should continue there. #2 is the cause of the problem, then all we can do is point you to #3. If #3 fails for some reason, then we should investigate this. However, be aware that the Unicode database has a fixed set of case mappings and we currently don't support extended case mapping which is locale and context sensitive. Again, patches are welcome. Please provide your examples using the repr() of the string or Unicode objects in question. This makes it a lot easier to test your examples on other platforms. Thanks. ---------------------------------------------------------------------- Comment By: Ahmet Bi?kinler (ahmetbiskinler) Date: 2006-08-21 10:55 Message: Logged In: YES user_id=1481281 There are still some problems with it. As in the image. http://img205.imageshack.us/img205/3998/turkishcharpythonyu5.jpg The upper() works fine(except ? and i uppercase) with IDLE since upper() doesn't even work. Another problem is with the ?(dotless) and i(dotted) 's upper. ?(dotless) should be I (dotless) i(dotted) should be ? (dotted) ? = I i = ? For more information: http://www.i18nguy.com/unicode/turkish-i18n.html ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-18 17:37 Message: Logged In: YES user_id=178886 Done: Bug #1542677 ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 22:08 Message: Logged In: YES user_id=849994 Please submit that as a separate IDLE bug. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 21:58 Message: Logged In: YES user_id=178886 Idle from 2.5rc1 (svn today) produces a different result than console (with my default, utf-8, encoding): IDLE 1.2c1 >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ?? >>> print len(u"?") 2 >>> print u"?".upper() ?? >>> str(u"?") Traceback (most recent call last): File "", line 1, in str(u"?") UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128) Again, IDLE 1.1.3 (python 2.4.3) produces a different result: IDLE 1.1.3 >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ?? >>> print len(u"?") 2 >>> print u"?".upper() ?? >>> str(u"?") '\xc3\x83\xc2\xa1' >>> I'd say idle is broken, as it is not able to respect utf-8 for print (or even len) of unicode strings. OTOH, with some tricks I can manage to get an accented a in a unicode in idle: >>> import unicodedata >>> print unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE") ? >>> print len(unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE")) 1 ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 18:08 Message: Logged In: YES user_id=849994 Using Unicode strings, the OP's example works. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-17 18:04 Message: Logged In: YES user_id=38388 String upper and lower conversion are locale dependent and implemented by the underlying libc, whereas Unicode upper/lower conversion is not and only depends on the Unicode character database. OTOH, there are special cases where the standard Unicode upper/lower mapping is no what you might expect, since the database only provides a single mapping and is not context aware. There's nothing we can do if the libc is broken in some respect. As for the extended case mapping support in Unicode: patches are welcome. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 18:03 Message: Logged In: YES user_id=849994 sgala: it looks like your console sends UTF-8 encoded text. >>> print "?" ? print is just printing out a byte string consisting of two bytes, which your console displays as accent-a. >>> print len("?") 2 A UTF-8-encoded string containing an accented a has two bytes. >>> print "?".upper() ? str.upper() doesn't take locale into account, so the accented a has no uppercase version defined. >>> str("?") '\xc3\xa1' str() applied to a byte string returns that byte string. Since return values from functions are printed by the interactive interpreter using repr() first, you get this representation (which you could also get from "print repr('a')".) >>> print u"?" ? That's also okay. Python knows the terminal encoding and properly translates the byte string to a unicode string of one character. On printout, it converts it to a UTF-8 string again, which your terminal displays correctly. >>> print len(u"?") 1 Since your two-byte-UTF-8 sequence is converted to a unicode character, the length of this unicode string is 1. >>> print u"?".upper() ? There are comprehensive capitalization tables available for unicode. >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) Applying str() to a unicode string must convert it to a byte string. If you don't specify an encoding, the default encoding is "ascii", which can't encode the accented a. Use "a".encode("utf-8"). ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 17:59 Message: Logged In: YES user_id=178886 (I tested it in 2.5rc1), 2.4 gives >>> str(u"?") '\xc3\xa1' instead of the exception ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 17:53 Message: Logged In: YES user_id=178886 The behaviour of python in this area is confusing. See a session with my Spanish keyboard: >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ? >>> print len(u"?") 1 >>> print u"?".upper() ? >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) I guess this is what is happening to the reporter. This violates the least surprising behavior principle in so many different ways that it hurts. Can anybody make sense of it? ---------------------------------------------------------------------- Comment By: Ahmet Bi?kinler (ahmetbiskinler) Date: 2006-08-11 11:10 Message: Logged In: YES user_id=1481281 What happened? Is it solved? How is it going? What is the final step? ...? ...? Could you please give me some information about the bug please? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 From noreply at sourceforge.net Mon Aug 28 15:59:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 06:59:06 -0700 Subject: [ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9 Message-ID: Bugs item #1542949, was opened at 2006-08-18 21:51 Message generated for change (Comment added) made by kbk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 Please note that this 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.5 Status: Open Resolution: None >Priority: 6 Submitted By: David Strozzi (dstrozzi) >Assigned to: Ronald Oussoren (ronaldoussoren) Summary: idle in python 2.5c1 freezes on macos 10.3.9 Initial Comment: Hi, I installed python 2.5b3 on a powerbook ppc laptop running macos 10.3.9 a few days ago. python and idle worked. Now I installed 2.5c1. python works fine from a terminal. When I start idle, it loads, puts up its menu bar, opens a shell window, displays usual startup info, and gives me a prompt. But, I can't type or get a cursor. Whenever I move the mouse over the idle window or menu bar, I get a spinning color wheel and can't do anything. I deleted the whole /library/python tree, reinstalled 2.5c1, and exactly the same thing happened. Oh, and I rebooted :) Not sure what is happening, or how to diagnose. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-28 09:59 Message: Logged In: YES user_id=149084 Maybe priority should be higher? Hopefully Ronald has time to look at this; I don't have access to a Mac. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 From noreply at sourceforge.net Mon Aug 28 16:05:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 07:05:18 -0700 Subject: [ python-Bugs-1547931 ] Typo in Language Reference Section 3.2 Class Instances Message-ID: Bugs item #1547931, was opened at 2006-08-28 10:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1547931&group_id=5470 Please note that this 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: whesse_at_clarkson (whesse1) Assigned to: Nobody/Anonymous (nobody) Summary: Typo in Language Reference Section 3.2 Class Instances Initial Comment: In the Python Language Reference, Section 3.2, subsection "Class Instances", HTML version, the sentence ending "... user-defined method object whose im_class attribute is C whose im_self attribute is the instance. " should add the word "and" to read "... user-defined method object whose im_class attribute is C and whose im_self attribute is the instance. " ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1547931&group_id=5470 From noreply at sourceforge.net Mon Aug 28 17:22:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 08:22:39 -0700 Subject: [ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9 Message-ID: Bugs item #1542949, was opened at 2006-08-19 03:51 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 6 Submitted By: David Strozzi (dstrozzi) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: idle in python 2.5c1 freezes on macos 10.3.9 Initial Comment: Hi, I installed python 2.5b3 on a powerbook ppc laptop running macos 10.3.9 a few days ago. python and idle worked. Now I installed 2.5c1. python works fine from a terminal. When I start idle, it loads, puts up its menu bar, opens a shell window, displays usual startup info, and gives me a prompt. But, I can't type or get a cursor. Whenever I move the mouse over the idle window or menu bar, I get a spinning color wheel and can't do anything. I deleted the whole /library/python tree, reinstalled 2.5c1, and exactly the same thing happened. Oh, and I rebooted :) Not sure what is happening, or how to diagnose. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 17:22 Message: Logged In: YES user_id=580910 I can reproduce this on 10.3.9: IDLE starts and opens the interactive window, but then completely blocks (spinning cursor). If I start IDLE from the commandline (/Applications/MacPython\ 2.5/ IDLE.app/Contents/MacOS/IDLE) I get a message about 'console' not being a valid command name. That requires further looking into, but is a red herring for this particular problem, removing the Tk-console hiding code in macosxSupport.py results in the same behaviour, without any further output on the console as well. Upgrading aquatk to the latest version (8.4.10.0) on tcltkaqua.sf.net didn't help, IDLE still hangs (Duh, that's because there's a /System/Library/ Frameworks/Tk.framework, which means a user install won't be used for IDLE). The problem is also unrelated to my IDLE.app work, the same problem occurs when starting $prefix/lib/python2.5/idlelib/idle.py. According to gdb the IDLE process is handing in a semaphore call inside the Tcl mainloop. Time to get into serious debugging mode I guess :-( BTW. IDLE does work correctly on a 10.4.7 system. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-28 15:59 Message: Logged In: YES user_id=149084 Maybe priority should be higher? Hopefully Ronald has time to look at this; I don't have access to a Mac. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 From noreply at sourceforge.net Mon Aug 28 17:48:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 08:48:35 -0700 Subject: [ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9 Message-ID: Bugs item #1542949, was opened at 2006-08-18 21:51 Message generated for change (Comment added) made by dstrozzi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 6 Submitted By: David Strozzi (dstrozzi) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: idle in python 2.5c1 freezes on macos 10.3.9 Initial Comment: Hi, I installed python 2.5b3 on a powerbook ppc laptop running macos 10.3.9 a few days ago. python and idle worked. Now I installed 2.5c1. python works fine from a terminal. When I start idle, it loads, puts up its menu bar, opens a shell window, displays usual startup info, and gives me a prompt. But, I can't type or get a cursor. Whenever I move the mouse over the idle window or menu bar, I get a spinning color wheel and can't do anything. I deleted the whole /library/python tree, reinstalled 2.5c1, and exactly the same thing happened. Oh, and I rebooted :) Not sure what is happening, or how to diagnose. ---------------------------------------------------------------------- >Comment By: David Strozzi (dstrozzi) Date: 2006-08-28 11:48 Message: Logged In: YES user_id=1056922 Well, if there's anything I can do as a 10.3.9 user to test this, let me know. Too busy to delve into the python source code though... ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 11:22 Message: Logged In: YES user_id=580910 I can reproduce this on 10.3.9: IDLE starts and opens the interactive window, but then completely blocks (spinning cursor). If I start IDLE from the commandline (/Applications/MacPython\ 2.5/ IDLE.app/Contents/MacOS/IDLE) I get a message about 'console' not being a valid command name. That requires further looking into, but is a red herring for this particular problem, removing the Tk-console hiding code in macosxSupport.py results in the same behaviour, without any further output on the console as well. Upgrading aquatk to the latest version (8.4.10.0) on tcltkaqua.sf.net didn't help, IDLE still hangs (Duh, that's because there's a /System/Library/ Frameworks/Tk.framework, which means a user install won't be used for IDLE). The problem is also unrelated to my IDLE.app work, the same problem occurs when starting $prefix/lib/python2.5/idlelib/idle.py. According to gdb the IDLE process is handing in a semaphore call inside the Tcl mainloop. Time to get into serious debugging mode I guess :-( BTW. IDLE does work correctly on a 10.4.7 system. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-28 09:59 Message: Logged In: YES user_id=149084 Maybe priority should be higher? Hopefully Ronald has time to look at this; I don't have access to a Mac. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 From noreply at sourceforge.net Mon Aug 28 18:43:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 09:43:24 -0700 Subject: [ python-Bugs-1479785 ] Quitter object masked Message-ID: Bugs item #1479785, was opened at 2006-05-01 17:01 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479785&group_id=5470 Please note that this 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.5 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Jim Jewett (jimjjewett) Assigned to: Kurt B. Kaiser (kbk) Summary: Quitter object masked Initial Comment: 2.5 introduces a Quitter object (defined in site.py) to make the quit/exit message more friendly. Lines 480-482 of PyShell.py override this, so that users of Idle never see the improved feature. Unfortunately, simply removing those lines isn't quite enough to solve the problem, as IDLE catches SystemExit exceptions. Getting around that, I didn't have time to track down yet. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 18:43 Message: Logged In: YES user_id=580910 When I type quit() in the Python Shell window I get a dialog that says: > The program is still running! > Do you want to kill it? (Python 2.5c1) ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-16 07:03 Message: Logged In: YES user_id=149084 Rev 51306: Patch #1540892 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1479785&group_id=5470 From noreply at sourceforge.net Mon Aug 28 18:59:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 09:59:04 -0700 Subject: [ python-Bugs-1542949 ] idle in python 2.5c1 freezes on macos 10.3.9 Message-ID: Bugs item #1542949, was opened at 2006-08-19 03:51 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 6 Submitted By: David Strozzi (dstrozzi) Assigned to: Ronald Oussoren (ronaldoussoren) Summary: idle in python 2.5c1 freezes on macos 10.3.9 Initial Comment: Hi, I installed python 2.5b3 on a powerbook ppc laptop running macos 10.3.9 a few days ago. python and idle worked. Now I installed 2.5c1. python works fine from a terminal. When I start idle, it loads, puts up its menu bar, opens a shell window, displays usual startup info, and gives me a prompt. But, I can't type or get a cursor. Whenever I move the mouse over the idle window or menu bar, I get a spinning color wheel and can't do anything. I deleted the whole /library/python tree, reinstalled 2.5c1, and exactly the same thing happened. Oh, and I rebooted :) Not sure what is happening, or how to diagnose. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 18:59 Message: Logged In: YES user_id=580910 I've created a new installer from the head of the release25-maint branch and that works correctly. I'm keeping this issue open because I want to investigate why 2.5c1 doesn't work while the current head of the 2.5 branch does work. ---------------------------------------------------------------------- Comment By: David Strozzi (dstrozzi) Date: 2006-08-28 17:48 Message: Logged In: YES user_id=1056922 Well, if there's anything I can do as a 10.3.9 user to test this, let me know. Too busy to delve into the python source code though... ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-08-28 17:22 Message: Logged In: YES user_id=580910 I can reproduce this on 10.3.9: IDLE starts and opens the interactive window, but then completely blocks (spinning cursor). If I start IDLE from the commandline (/Applications/MacPython\ 2.5/ IDLE.app/Contents/MacOS/IDLE) I get a message about 'console' not being a valid command name. That requires further looking into, but is a red herring for this particular problem, removing the Tk-console hiding code in macosxSupport.py results in the same behaviour, without any further output on the console as well. Upgrading aquatk to the latest version (8.4.10.0) on tcltkaqua.sf.net didn't help, IDLE still hangs (Duh, that's because there's a /System/Library/ Frameworks/Tk.framework, which means a user install won't be used for IDLE). The problem is also unrelated to my IDLE.app work, the same problem occurs when starting $prefix/lib/python2.5/idlelib/idle.py. According to gdb the IDLE process is handing in a semaphore call inside the Tcl mainloop. Time to get into serious debugging mode I guess :-( BTW. IDLE does work correctly on a 10.4.7 system. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2006-08-28 15:59 Message: Logged In: YES user_id=149084 Maybe priority should be higher? Hopefully Ronald has time to look at this; I don't have access to a Mac. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1542949&group_id=5470 From noreply at sourceforge.net Mon Aug 28 19:47:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 10:47:50 -0700 Subject: [ python-Bugs-1548092 ] curses module segfaults on invalid tparm arguments Message-ID: Bugs item #1548092, was opened at 2006-08-28 19:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548092&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marien Zwart (marienz) Assigned to: Nobody/Anonymous (nobody) Summary: curses module segfaults on invalid tparm arguments Initial Comment: At least on my platform the ncurses "tparm" function returns NULL on certain invalid arguments. PyCurses_tparm does not check the return value, it just passes it to PyString_FromString. This means: python -c "import curses;curses.setupterm();print curses.tparm('', curses.COLOR_GREEN)" gives me: zsh: segmentation fault python -c (tested with python 2.4.3) I am not sure what the best fix is. An exception would make sense to me, but the (related) tigetstr function returns None to python if the wrapped c function returns NULL, and I have not used the curses module enough to know what is more common. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548092&group_id=5470 From noreply at sourceforge.net Mon Aug 28 22:47:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 13:47:11 -0700 Subject: [ python-Bugs-1548178 ] Add 'find' method to sequence types Message-ID: Bugs item #1548178, was opened at 2006-08-28 22: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=1548178&group_id=5470 Please note that this 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: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: kovan (kovan) Assigned to: Nobody/Anonymous (nobody) Summary: Add 'find' method to sequence types Initial Comment: In the benefit of Python's readability and simplicity, a 'find' method could be added to sequence types, that would return the first item in the list that matches some criteria. For example, it's a common practice to use lists of (key,value) pairs instead of dictionaries when the sequence must be ordered. To find an element maching a key in such cases, I frequently find myself writing (IMHO) too much code for such a straightforward operation. AFAIK currently there are two easy ways to do this (shouln't be one, and only one?): for item in items: if item.attribute == key: foundItem = item break else: foundItem = None OR foundItems = [item for item in items if item.key == value] if foundItems: foundItem = foundItem[0] IMO, in none of the cases the code is as clear and, specially, as short, as it should be. With the find method, the same code would be: item = items.find(lambda x: x.key == value) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548178&group_id=5470 From noreply at sourceforge.net Mon Aug 28 23:22:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 14:22:25 -0700 Subject: [ python-Bugs-1548178 ] Add 'find' method to sequence types Message-ID: Bugs item #1548178, was opened at 2006-08-28 22:47 Message generated for change (Settings changed) made by kovan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548178&group_id=5470 Please note that this 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: Feature Request Status: Open Resolution: None >Priority: 4 Submitted By: kovan (kovan) Assigned to: Nobody/Anonymous (nobody) Summary: Add 'find' method to sequence types Initial Comment: In the benefit of Python's readability and simplicity, a 'find' method could be added to sequence types, that would return the first item in the list that matches some criteria. For example, it's a common practice to use lists of (key,value) pairs instead of dictionaries when the sequence must be ordered. To find an element maching a key in such cases, I frequently find myself writing (IMHO) too much code for such a straightforward operation. AFAIK currently there are two easy ways to do this (shouln't be one, and only one?): for item in items: if item.attribute == key: foundItem = item break else: foundItem = None OR foundItems = [item for item in items if item.key == value] if foundItems: foundItem = foundItem[0] IMO, in none of the cases the code is as clear and, specially, as short, as it should be. With the find method, the same code would be: item = items.find(lambda x: x.key == value) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548178&group_id=5470 From noreply at sourceforge.net Tue Aug 29 02:05:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 17:05:42 -0700 Subject: [ python-Bugs-1548252 ] Recursion limit exceeded in the match function Message-ID: Bugs item #1548252, was opened at 2006-08-29 02:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548252&group_id=5470 Please note that this 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: wojtekwu (wojtekwu) Assigned to: Nobody/Anonymous (nobody) Summary: Recursion limit exceeded in the match function Initial Comment: Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> exp = re.compile("((a*)(b*))*") >>> result = exp.match("a") Traceback (most recent call last): File "", line 1, in ? RuntimeError: maximum recursion limit exceeded >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548252&group_id=5470 From noreply at sourceforge.net Tue Aug 29 03:31:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 18:31:02 -0700 Subject: [ python-Bugs-1548252 ] Recursion limit exceeded in the match function Message-ID: Bugs item #1548252, was opened at 2006-08-28 21:05 Message generated for change (Comment added) made by andresriancho You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548252&group_id=5470 Please note that this 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: wojtekwu (wojtekwu) Assigned to: Nobody/Anonymous (nobody) Summary: Recursion limit exceeded in the match function Initial Comment: Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> exp = re.compile("((a*)(b*))*") >>> result = exp.match("a") Traceback (most recent call last): File "", line 1, in ? RuntimeError: maximum recursion limit exceeded >>> ---------------------------------------------------------------------- Comment By: Andres Riancho (andresriancho) Date: 2006-08-28 22:31 Message: Logged In: YES user_id=1284064 I tried this on: Python 2.4.3 (#2, Apr 27 2006, 14:43:58) seems to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548252&group_id=5470 From noreply at sourceforge.net Tue Aug 29 04:32:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 19:32:15 -0700 Subject: [ python-Bugs-1548288 ] sgmllib.sgmlparser is not thread safe Message-ID: Bugs item #1548288, was opened at 2006-08-28 23:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548288&group_id=5470 Please note that this 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: Andres Riancho (andresriancho) Assigned to: Nobody/Anonymous (nobody) Summary: sgmllib.sgmlparser is not thread safe Initial Comment: Python version: =============== dz0 at fre3ak:~$ python Python 2.4.3 (#2, Apr 27 2006, 14:43:58) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Problem description: ==================== sgmlparser is not thread safe, i discovered this problem when trying to fetch and parse many html files at the same time. An example of this bug can be found attached. The sgmlparser input html is this string: ''*100 , this was written this way to simplify the code, please note that if you replace this string with a "large" html document, it will also fail. solution: ========= make the lib thread safe, or add some lines to the documentation saying that it aint thread safe. Traceback: ========== python sgml-not-threadSafe.py Started all threads Successfully parsed html Exception in thread Thread-3: Traceback (most recent call last): File "/usr/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/lib/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "sgml-not-threadSafe.py", line 10, in parseHtml self._parser.feed( html ) File "/usr/lib/python2.4/sgmllib.py", line 95, in feed self.goahead(0) File "/usr/lib/python2.4/sgmllib.py", line 129, in goahead k = self.parse_starttag(i) File "/usr/lib/python2.4/sgmllib.py", line 262, in parse_starttag self.error('unexpected call to parse_starttag') File "/usr/lib/python2.4/sgmllib.py", line 102, in error raise SGMLParseError(message) SGMLParseError: unexpected call to parse_starttag Successfully parsed html Successfully parsed html Additional note =============== To recreate this bug, you should run the sample code more than one time. Thread handling aint always the same, the issue is there but sometimes it fails to appear on the first (second, third...) run. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548288&group_id=5470 From noreply at sourceforge.net Tue Aug 29 07:51:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 28 Aug 2006 22:51:11 -0700 Subject: [ python-Bugs-1548332 ] whichdb too dumb Message-ID: Bugs item #1548332, was opened at 2006-08-28 22:51 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548332&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Curtis Doty (dotysan) Assigned to: Nobody/Anonymous (nobody) Summary: whichdb too dumb Initial Comment: On my system with db4, I noticed that whichdb doesn't know anything about more recent database types created by the bsddb module. Python 2.4.3 (#1, Jun 13 2006, 11:46:08) [GCC 4.1.1 20060525 (Red Hat 4.1.1-1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> >>> from whichdb import * >>> import bsddb >>> >>> dbfile= "hash" >>> bsddb.hashopen( dbfile) {} >>> whichdb( dbfile) 'dbhash' >>> # yay ... >>> dbfile= "btree" >>> bsddb.btopen( dbfile) {} >>> whichdb( dbfile) '' >>> # bah ... >>> dbfile= "recno" >>> bsddb.rnopen( dbfile) {} >>> whichdb( dbfile) '' >>> # humbug! It looks like both these database types share: #define DB_BTREEMAGIC 0x053162 So this might be a start: --- Python-2.5c1/Lib/whichdb.py.orig 2005-02-05 22:57:08.000000000 -0800 +++ Python-2.5c1/Lib/whichdb.py 2006-08-28 13:46:57.000000000 -0700 @@ -109,6 +109,10 @@ if magic in (0x00061561, 0x61150600): return "dbhash" + # Check for binary tree + if magic == 0x00053162: + return "btree" + # Unknown return "" But alas, I'm not clear on the best way to differentiate between btree and recno. The above example is on 2.4 but persists in 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548332&group_id=5470 From noreply at sourceforge.net Tue Aug 29 09:03:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Aug 2006 00:03:23 -0700 Subject: [ python-Feature Requests-1548178 ] Add 'find' method to sequence types Message-ID: Feature Requests item #1548178, was opened at 2006-08-28 20:47 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1548178&group_id=5470 Please note that this 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: 4 Submitted By: kovan (kovan) Assigned to: Nobody/Anonymous (nobody) Summary: Add 'find' method to sequence types Initial Comment: In the benefit of Python's readability and simplicity, a 'find' method could be added to sequence types, that would return the first item in the list that matches some criteria. For example, it's a common practice to use lists of (key,value) pairs instead of dictionaries when the sequence must be ordered. To find an element maching a key in such cases, I frequently find myself writing (IMHO) too much code for such a straightforward operation. AFAIK currently there are two easy ways to do this (shouln't be one, and only one?): for item in items: if item.attribute == key: foundItem = item break else: foundItem = None OR foundItems = [item for item in items if item.key == value] if foundItems: foundItem = foundItem[0] IMO, in none of the cases the code is as clear and, specially, as short, as it should be. With the find method, the same code would be: item = items.find(lambda x: x.key == value) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1548178&group_id=5470 From noreply at sourceforge.net Tue Aug 29 09:03:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Aug 2006 00:03:43 -0700 Subject: [ python-Bugs-1548252 ] Recursion limit exceeded in the match function Message-ID: Bugs item #1548252, was opened at 2006-08-29 00:05 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548252&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: wojtekwu (wojtekwu) Assigned to: Nobody/Anonymous (nobody) Summary: Recursion limit exceeded in the match function Initial Comment: Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import re >>> exp = re.compile("((a*)(b*))*") >>> result = exp.match("a") Traceback (most recent call last): File "", line 1, in ? RuntimeError: maximum recursion limit exceeded >>> ---------------------------------------------------------------------- Comment By: Andres Riancho (andresriancho) Date: 2006-08-29 01:31 Message: Logged In: YES user_id=1284064 I tried this on: Python 2.4.3 (#2, Apr 27 2006, 14:43:58) seems to be fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548252&group_id=5470 From noreply at sourceforge.net Tue Aug 29 09:27:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Aug 2006 00:27:59 -0700 Subject: [ python-Bugs-1548371 ] filterwarnings('error') has no effect Message-ID: Bugs item #1548371, was opened at 2006-08-29 02: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=1548371&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: filterwarnings('error') has no effect Initial Comment: Once a warning has already been issued, warnings.filterwarnings('error',...) will not cause an error to be raised. When the attached script is run, the warning is printed the first time thru the loop, but no error is raised the 2nd time thru. Likewise, warnings.filterwarnings('always',...) will not cause the warning to be printed again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548371&group_id=5470 From noreply at sourceforge.net Tue Aug 29 09:35:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Aug 2006 00:35:55 -0700 Subject: [ python-Bugs-1545837 ] array.array borks on deepcopy Message-ID: Bugs item #1545837, was opened at 2006-08-24 11:49 Message generated for change (Comment added) made by twouters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&group_id=5470 Please note that this 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: Later Priority: 7 Submitted By: V?clav Haisman (wilx) Assigned to: Anthony Baxter (anthonybaxter) Summary: array.array borks on deepcopy Initial Comment: Hi, I think there is a bug arraymodule.c this line: {"__deepcopy__",(PyCFunction)array_copy, METH_NOARGS, copy_doc}, should probably have METH_O instead of METH_NOARGS there, since according to docs and the prototype of the array_copy() function there is one parameter. ---------------------------------------------------------------------- >Comment By: Thomas Wouters (twouters) Date: 2006-08-29 09:35 Message: Logged In: YES user_id=34209 Not unless you want another release candidate. copy.deepcopy has never worked on array instances, so it's not a release-preventing bug (but each bugfix may *add* a release-preventing bug by accident :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-08-28 15:32 Message: Logged In: YES user_id=80475 Should this be fixed in the release candidate? ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2006-08-24 20:50 Message: Logged In: YES user_id=34209 Thanks! Fixed in the trunk (which is 2.6-to-be) revision 51565, and it will also be fixed for Python 2.4.4 and 2.5.1. It's unfortunately just a bit too late for 2.5.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&group_id=5470 From noreply at sourceforge.net Tue Aug 29 13:29:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Aug 2006 04:29:43 -0700 Subject: [ python-Bugs-1546628 ] urlparse.urljoin odd behaviour Message-ID: Bugs item #1546628, was opened at 2006-08-25 23:04 Message generated for change (Comment added) made by the_j10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546628&group_id=5470 Please note that this 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: Andres Riancho (andresriancho) Assigned to: Nobody/Anonymous (nobody) Summary: urlparse.urljoin odd behaviour Initial Comment: Hi ! I think i have found a bug on the urljoin function of the urlparse module. I'm using Python 2.4.3 (#2, Apr 27 2006, 14:43:58), [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 . Here is a demo of the bug : >>> import urlparse >>>urlparse.urljoin('http://www.f00.com/','//a') 'http://a' >>> urlparse.urljoin('http://www.f00.com/','https://0000/somethingIsWrong') 'https://0000/somethingIsWrong' >>> urlparse.urljoin('http://www.f00.com/','https://0000/somethingIsWrong') 'https://0000/somethingIsWrong' >>> urlparse.urljoin('http://www.f00.com/','file:///etc/passwd') 'file:///etc/passwd' The result for the first call to urljoin should be either 'http://www.f00.com/a' or 'http://www.f00.com//a'. The result to the second and third call to urljoin should be 'http://www.f00.com/', or maybe an exception ? Please correct me if i'm wrong and this is some kind of feature or the bug was already reported. This bug can result in a security vuln, take this code as an example: // viewImage.py // import htmlTools # Some fake module, just for the example import urlparse # module with bug. htmlTools.startHtml() # print params = htmlTools.getParams() # get the query string parameters htmlTools.printToHtml( '' ) htmlTools.endHtml() # print // viewImage.py // The code should generate an html that shows an image from the site http://myWebsite/, but with the urljoin bug, the image source can be manipulated and result in a completely different html. Cheers, Andres Riancho ---------------------------------------------------------------------- Comment By: Andrew Jones (the_j10) Date: 2006-08-29 21:29 Message: Logged In: YES user_id=332575 The second argument in the urljoin method can be either an absolute url or a relative url as specified by rfc1808. So your 1st example: '//a' gives a relative position w.r.t the base resulting in: 'http://a'. This is similar to how `cd /boot` takes you to a path relative to the filesystem's root '/'. In the rest of your examples you have the scheme name 'https'in the url as the 2nd argument. urljoin follows the rfc1808 and accepts the second argument if it has a scheme name as the absolute url and returns it. This behavior is not very intuitive. Perhaps the urlparse could be extended to have a urlappend method, which has the behavior you expected. Hmmm... -- Andrew ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546628&group_id=5470 From noreply at sourceforge.net Tue Aug 29 18:09:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Aug 2006 09:09:12 -0700 Subject: [ python-Bugs-1548687 ] C modules reloaded on certain failed imports Message-ID: Bugs item #1548687, was opened at 2006-08-29 09:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548687&group_id=5470 Please note that this 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: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: C modules reloaded on certain failed imports Initial Comment: Running z.py in the attached archive should produce an attribute error on printing, as we have set sys.stdout to None. On 2.3.5 and 2.4.3, output is printed and any imported C modules in x/y.py are reloaded, builtin or 3rd party. On 2.5, we get a traceback on import: "SystemError: Parent module 'x' not loaded". Changing the name on the import from 'x.y' to 'y' works-around the error, and we get the expected AttributeError in 2.3, 2.4. 2.5 gives us the same SystemError. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548687&group_id=5470 From noreply at sourceforge.net Tue Aug 29 19:43:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Aug 2006 10:43:30 -0700 Subject: [ python-Bugs-1528802 ] Turkish Character Message-ID: Bugs item #1528802, was opened at 2006-07-26 09:05 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 Please note that this 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.5 Status: Open Resolution: None Priority: 6 Submitted By: Ahmet Bi?kinler (ahmetbiskinler) Assigned to: M.-A. Lemburg (lemburg) Summary: Turkish Character Initial Comment: >>> print "May?s".upper() >>> MAY?S >>> import locale >>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254') >>> print "May?s".upper() >>> MAY?S >>> print "???i???".upper() >>> ???I??? MAY?S should be MAYIS ???I??? should be ??????I but >>> "May?s".upper() >>> "MAYIS" is right ---------------------------------------------------------------------- >Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-29 19:43 Message: Logged In: YES user_id=38388 Could you test this with Unicode strings, ie. u"...".upper() ? It would also help if you'd provide the repr()-version of the strings - makes testing on non-Turkish systems easier. Thanks. ---------------------------------------------------------------------- Comment By: Ahmet Bi?kinler (ahmetbiskinler) Date: 2006-08-28 15:57 Message: Logged In: YES user_id=1481281 As you saw in the picture the IDLE does its work. Its is the one who is working right. The python interpreter(C:\Python25\Python.exe) has the problem with it. Does the interpreter generate bug reports if there is no crashing or else... And I don't know how to file an IDLE bug report from the interpreter(C:\Python25\Python.exe). ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-21 12:01 Message: Logged In: YES user_id=38388 Could we please get some things straight first: 1. if you're working with IDLE and it doesn't do what you expect it to, please file an IDLE bug report, not a Python one; the same it true for any other Python IDE you are using 2. string's .lower() and .upper() method rely 100% on the platform's C lib implementation of these functions; there's nothing Python can do about bugs in these implementations 3. if you want reproducable behavior across platforms, please always use Unicode, *not* 8-bit strings, for text data. I see that #1 has already been done, so the IDLE specific discussion should continue there. #2 is the cause of the problem, then all we can do is point you to #3. If #3 fails for some reason, then we should investigate this. However, be aware that the Unicode database has a fixed set of case mappings and we currently don't support extended case mapping which is locale and context sensitive. Again, patches are welcome. Please provide your examples using the repr() of the string or Unicode objects in question. This makes it a lot easier to test your examples on other platforms. Thanks. ---------------------------------------------------------------------- Comment By: Ahmet Bi?kinler (ahmetbiskinler) Date: 2006-08-21 09:55 Message: Logged In: YES user_id=1481281 There are still some problems with it. As in the image. http://img205.imageshack.us/img205/3998/turkishcharpythonyu5.jpg The upper() works fine(except ? and i uppercase) with IDLE since upper() doesn't even work. Another problem is with the ?(dotless) and i(dotted) 's upper. ?(dotless) should be I (dotless) i(dotted) should be ? (dotted) ? = I i = ? For more information: http://www.i18nguy.com/unicode/turkish-i18n.html ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-18 16:37 Message: Logged In: YES user_id=178886 Done: Bug #1542677 ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 21:08 Message: Logged In: YES user_id=849994 Please submit that as a separate IDLE bug. ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 20:58 Message: Logged In: YES user_id=178886 Idle from 2.5rc1 (svn today) produces a different result than console (with my default, utf-8, encoding): IDLE 1.2c1 >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ?? >>> print len(u"?") 2 >>> print u"?".upper() ?? >>> str(u"?") Traceback (most recent call last): File "", line 1, in str(u"?") UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128) Again, IDLE 1.1.3 (python 2.4.3) produces a different result: IDLE 1.1.3 >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ?? >>> print len(u"?") 2 >>> print u"?".upper() ?? >>> str(u"?") '\xc3\x83\xc2\xa1' >>> I'd say idle is broken, as it is not able to respect utf-8 for print (or even len) of unicode strings. OTOH, with some tricks I can manage to get an accented a in a unicode in idle: >>> import unicodedata >>> print unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE") ? >>> print len(unicodedata.lookup("LATIN SMALL LETTER A WITH ACUTE")) 1 ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 17:08 Message: Logged In: YES user_id=849994 Using Unicode strings, the OP's example works. ---------------------------------------------------------------------- Comment By: M.-A. Lemburg (lemburg) Date: 2006-08-17 17:04 Message: Logged In: YES user_id=38388 String upper and lower conversion are locale dependent and implemented by the underlying libc, whereas Unicode upper/lower conversion is not and only depends on the Unicode character database. OTOH, there are special cases where the standard Unicode upper/lower mapping is no what you might expect, since the database only provides a single mapping and is not context aware. There's nothing we can do if the libc is broken in some respect. As for the extended case mapping support in Unicode: patches are welcome. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-17 17:03 Message: Logged In: YES user_id=849994 sgala: it looks like your console sends UTF-8 encoded text. >>> print "?" ? print is just printing out a byte string consisting of two bytes, which your console displays as accent-a. >>> print len("?") 2 A UTF-8-encoded string containing an accented a has two bytes. >>> print "?".upper() ? str.upper() doesn't take locale into account, so the accented a has no uppercase version defined. >>> str("?") '\xc3\xa1' str() applied to a byte string returns that byte string. Since return values from functions are printed by the interactive interpreter using repr() first, you get this representation (which you could also get from "print repr('a')".) >>> print u"?" ? That's also okay. Python knows the terminal encoding and properly translates the byte string to a unicode string of one character. On printout, it converts it to a UTF-8 string again, which your terminal displays correctly. >>> print len(u"?") 1 Since your two-byte-UTF-8 sequence is converted to a unicode character, the length of this unicode string is 1. >>> print u"?".upper() ? There are comprehensive capitalization tables available for unicode. >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) Applying str() to a unicode string must convert it to a byte string. If you don't specify an encoding, the default encoding is "ascii", which can't encode the accented a. Use "a".encode("utf-8"). ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 16:59 Message: Logged In: YES user_id=178886 (I tested it in 2.5rc1), 2.4 gives >>> str(u"?") '\xc3\xa1' instead of the exception ---------------------------------------------------------------------- Comment By: Santiago Gala (sgala) Date: 2006-08-17 16:53 Message: Logged In: YES user_id=178886 The behaviour of python in this area is confusing. See a session with my Spanish keyboard: >>> print "?" ? >>> print len("?") 2 >>> print "?".upper() ? >>> str("?") '\xc3\xa1' >>> print u"?" ? >>> print len(u"?") 1 >>> print u"?".upper() ? >>> str(u"?") Traceback (most recent call last): File "", line 1, in __builtin__.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe1' in position 0: ordinal not in range(128) I guess this is what is happening to the reporter. This violates the least surprising behavior principle in so many different ways that it hurts. Can anybody make sense of it? ---------------------------------------------------------------------- Comment By: Ahmet Bi?kinler (ahmetbiskinler) Date: 2006-08-11 10:10 Message: Logged In: YES user_id=1481281 What happened? Is it solved? How is it going? What is the final step? ...? ...? Could you please give me some information about the bug please? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&group_id=5470 From noreply at sourceforge.net Tue Aug 29 23:16:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Aug 2006 14:16:22 -0700 Subject: [ python-Bugs-1548891 ] shlex (or perhaps cStringIO) and unicode strings Message-ID: Bugs item #1548891, was opened at 2006-08-29 21:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548891&group_id=5470 Please note that this 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: Erwin S. Andreasen (drylock) Assigned to: Nobody/Anonymous (nobody) Summary: shlex (or perhaps cStringIO) and unicode strings Initial Comment: Python 2.5c1 (r25c1:51305, Aug 19 2006, 18:23:29) [GCC 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)] on linux2 (Also seen in 2.4) shlex.split do not like unicode strings: >>> shlex.split(u"foo") ['f\x00\x00\x00o\x00\x00\x00o\x00\x00\x00'] The shlex code IMO suggests that it should accept unicode (as it checks for argument being an instance of basestring). Digging slightly into this, this seems to be a difference between StringIO and cStringIO. While cStringIO claims it accepts unicode as long as it encode too ASCII it gives invalid results: >>> sys.getdefaultencoding() 'ascii' >>> cStringIO.StringIO(u'foo').getvalue() 'f\x00\x00\x00o\x00\x00\x00o\x00\x00\x00' Perhaps cStringIO should .encode to ASCII encoding before consuming the input, as I can't imagine anyone cares about the above result (which I guess are the UCS-2 or UCS-4 characters). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548891&group_id=5470 From noreply at sourceforge.net Wed Aug 30 07:06:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 29 Aug 2006 22:06:30 -0700 Subject: [ python-Bugs-1545696 ] structmember T_LONG won't accept a python long Message-ID: Bugs item #1545696, was opened at 2006-08-24 00:07 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: structmember T_LONG won't accept a python long Initial Comment: An attribute defined as T_LONG throws a vague error when set to a python long, even when the value is within the range of a LONG. TypeError: bad argument type for built-in operation ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-08-30 00:06 Message: Logged In: YES user_id=771074 Submitted patch 1549049. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-08-27 21:23 Message: Logged In: YES user_id=771074 In the process of creating a patch for this, I came across some more 'ugh'-liness. T_UINT's are returned via PyInt_FromLong, so you actually get back a negative value for large numbers. Changing it to use PyLong_FromUnsignedLong will break backward compatibility, but this is so wrong I can't possibly see keeping it. Your call. (plus it makes it impossible to test T_UINT with values larger than INT_MAX) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 19:52 Message: Logged In: YES user_id=33168 Ugh. This code is lax in checking/conversion. Do you think you could provide a patch? All of the int cases should call PyInt_AsLong() if this call fails (returns -1), then that should be returned from PyMember_SetOne. If it succeeds, there should be a range check that ensures the value is valid. If that fails a warning should be produced. We need to issue a warning rather than an error for backwards compatability (at least for 2.6). The float/double cases can be simplified some by calling PyFloat_AsDouble and doing similar checks as in the int cases. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-08-24 14:56 Message: Logged In: YES user_id=771074 The DEVMODE object from pywintypes has attributes defined as T_LONG via the structmember API. >>> import pywintypes >>> dm=pywintypes.DEVMODEType() >>> dm.Position_x=3 >>> dm.Position_x 3 >>> dm.Position_x=long(3) Traceback (most recent call last): File "", line 1, in ? TypeError: bad argument type for built-in operation >>> Here's the relevant code from structmember.c that throws the error: case T_LONG: if (!PyInt_Check(v)) { PyErr_BadArgument(); return -1; } *(long*)addr = PyInt_AsLong(v); break; ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-24 13:30 Message: Logged In: YES user_id=33168 Can you provide example code that demonstrates what you mean? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470 From noreply at sourceforge.net Wed Aug 30 15:22:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 30 Aug 2006 06:22:10 -0700 Subject: [ python-Bugs-1545463 ] New-style classes fail to cleanup attributes Message-ID: Bugs item #1545463, was opened at 2006-08-23 14:24 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 Please note that this 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: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: New-style classes fail to cleanup attributes Initial Comment: > cat x.py class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') class B: x = X('old') > python x.py creating X('new') creating X('old') deleting X('old') Python 2.4.2 (#2, Jan 13 2006, 12:00:38) Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-30 09:22 Message: Logged In: YES user_id=764593 The funny interaction with modules is probably that the module retains a reference to the class (and vice versa), so the class can't go away until the module does -- and a module in sys.modules can't go away. The __del__ methods are not called if the interpreter can't decide which to call first. For example, if A.attr=B B.attr=A then A and B form a cycle (like the class and its defining module). If only one has a __del__ method, it gets called, but if both do, then python doesn't know which to call first, so it never calls either. You may have a cycle like module <==> class <==>instanceA \ <==>instanceB So that it can't decide whether to take care of instanceA or instanceB first. Or it might be that the __del__ methods actually are being called, but not until module teardown has begun, so they don't work right. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 20:08 Message: Logged In: YES user_id=835142 I used __del__ just to illustrate the problem. In real life application, X was a type defined in a C module and I've noticed that it's tp_dealloc is not called on instances assigned to class variables. BTW, what are the circumstances when __del__() methods are not called for objects that still exist when the interpreter exits? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-23 19:18 Message: Logged In: YES user_id=849994 There's also this sentence in the __del__ docs: """ It is not guaranteed that __del__() methods are called for objects that still exist when the interpreter exits. """ ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 18:54 Message: Logged In: YES user_id=835142 Yes, I've found that (using gc.get_referrers!), but this does not explain why A is not cleaned up when the program exits. Note that if I put class A definition inside a function, it does get cleaned up. Must be some funny interation between module and new-style class objects. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-23 18:45 Message: Logged In: YES user_id=849994 Note that new-style classes are always part of a reference cycle (you can find this out via gc.get_referrers). Therefore, they will not be deleted instantly, but only after gc collects them (you can trigger that via gc.collect). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 18:01 Message: Logged In: YES user_id=835142 It looks like the class object is not deleted alltogether: class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') del A Output: creating X('new') deleting X('new') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 From noreply at sourceforge.net Wed Aug 30 15:34:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 30 Aug 2006 06:34:33 -0700 Subject: [ python-Bugs-1545463 ] New-style classes fail to cleanup attributes Message-ID: Bugs item #1545463, was opened at 2006-08-23 14:24 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 Please note that this 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: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: New-style classes fail to cleanup attributes Initial Comment: > cat x.py class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') class B: x = X('old') > python x.py creating X('new') creating X('old') deleting X('old') Python 2.4.2 (#2, Jan 13 2006, 12:00:38) Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-30 09:34 Message: Logged In: YES user_id=764593 Looking at your example code (as best I can guess about indentation), it looks like module x <==> class X module x <==> class A ==> A's instance x ==> class X module x <==> class B ==> B's instance x ==> class X So the x instances can't go away until A and B do, which means at module cleanup. But when the module cleans up, it may well clean up X before A, so that A.x no longer has an active class, so that it can't find its __del__ method. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-30 09:22 Message: Logged In: YES user_id=764593 The funny interaction with modules is probably that the module retains a reference to the class (and vice versa), so the class can't go away until the module does -- and a module in sys.modules can't go away. The __del__ methods are not called if the interpreter can't decide which to call first. For example, if A.attr=B B.attr=A then A and B form a cycle (like the class and its defining module). If only one has a __del__ method, it gets called, but if both do, then python doesn't know which to call first, so it never calls either. You may have a cycle like module <==> class <==>instanceA \ <==>instanceB So that it can't decide whether to take care of instanceA or instanceB first. Or it might be that the __del__ methods actually are being called, but not until module teardown has begun, so they don't work right. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 20:08 Message: Logged In: YES user_id=835142 I used __del__ just to illustrate the problem. In real life application, X was a type defined in a C module and I've noticed that it's tp_dealloc is not called on instances assigned to class variables. BTW, what are the circumstances when __del__() methods are not called for objects that still exist when the interpreter exits? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-23 19:18 Message: Logged In: YES user_id=849994 There's also this sentence in the __del__ docs: """ It is not guaranteed that __del__() methods are called for objects that still exist when the interpreter exits. """ ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 18:54 Message: Logged In: YES user_id=835142 Yes, I've found that (using gc.get_referrers!), but this does not explain why A is not cleaned up when the program exits. Note that if I put class A definition inside a function, it does get cleaned up. Must be some funny interation between module and new-style class objects. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-23 18:45 Message: Logged In: YES user_id=849994 Note that new-style classes are always part of a reference cycle (you can find this out via gc.get_referrers). Therefore, they will not be deleted instantly, but only after gc collects them (you can trigger that via gc.collect). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 18:01 Message: Logged In: YES user_id=835142 It looks like the class object is not deleted alltogether: class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') del A Output: creating X('new') deleting X('new') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 From noreply at sourceforge.net Wed Aug 30 15:36:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 30 Aug 2006 06:36:13 -0700 Subject: [ python-Bugs-1545463 ] New-style classes fail to cleanup attributes Message-ID: Bugs item #1545463, was opened at 2006-08-23 14:24 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 Please note that this 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: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: New-style classes fail to cleanup attributes Initial Comment: > cat x.py class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') class B: x = X('old') > python x.py creating X('new') creating X('old') deleting X('old') Python 2.4.2 (#2, Jan 13 2006, 12:00:38) Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-30 09:36 Message: Logged In: YES user_id=764593 I suggest changing status to Pending Close - not a bug. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-30 09:34 Message: Logged In: YES user_id=764593 Looking at your example code (as best I can guess about indentation), it looks like module x <==> class X module x <==> class A ==> A's instance x ==> class X module x <==> class B ==> B's instance x ==> class X So the x instances can't go away until A and B do, which means at module cleanup. But when the module cleans up, it may well clean up X before A, so that A.x no longer has an active class, so that it can't find its __del__ method. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-30 09:22 Message: Logged In: YES user_id=764593 The funny interaction with modules is probably that the module retains a reference to the class (and vice versa), so the class can't go away until the module does -- and a module in sys.modules can't go away. The __del__ methods are not called if the interpreter can't decide which to call first. For example, if A.attr=B B.attr=A then A and B form a cycle (like the class and its defining module). If only one has a __del__ method, it gets called, but if both do, then python doesn't know which to call first, so it never calls either. You may have a cycle like module <==> class <==>instanceA \ <==>instanceB So that it can't decide whether to take care of instanceA or instanceB first. Or it might be that the __del__ methods actually are being called, but not until module teardown has begun, so they don't work right. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 20:08 Message: Logged In: YES user_id=835142 I used __del__ just to illustrate the problem. In real life application, X was a type defined in a C module and I've noticed that it's tp_dealloc is not called on instances assigned to class variables. BTW, what are the circumstances when __del__() methods are not called for objects that still exist when the interpreter exits? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-23 19:18 Message: Logged In: YES user_id=849994 There's also this sentence in the __del__ docs: """ It is not guaranteed that __del__() methods are called for objects that still exist when the interpreter exits. """ ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 18:54 Message: Logged In: YES user_id=835142 Yes, I've found that (using gc.get_referrers!), but this does not explain why A is not cleaned up when the program exits. Note that if I put class A definition inside a function, it does get cleaned up. Must be some funny interation between module and new-style class objects. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-23 18:45 Message: Logged In: YES user_id=849994 Note that new-style classes are always part of a reference cycle (you can find this out via gc.get_referrers). Therefore, they will not be deleted instantly, but only after gc collects them (you can trigger that via gc.collect). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 18:01 Message: Logged In: YES user_id=835142 It looks like the class object is not deleted alltogether: class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') del A Output: creating X('new') deleting X('new') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 From noreply at sourceforge.net Wed Aug 30 15:53:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 30 Aug 2006 06:53:20 -0700 Subject: [ python-Bugs-1545463 ] New-style classes fail to cleanup attributes Message-ID: Bugs item #1545463, was opened at 2006-08-23 14:24 Message generated for change (Comment added) made by belopolsky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 Please note that this 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: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: New-style classes fail to cleanup attributes Initial Comment: > cat x.py class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') class B: x = X('old') > python x.py creating X('new') creating X('old') deleting X('old') Python 2.4.2 (#2, Jan 13 2006, 12:00:38) Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11) ---------------------------------------------------------------------- >Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-30 09:53 Message: Logged In: YES user_id=835142 Is it true that a class retains reference to the module? The '__module__' attribute is a string, not a reference to the module. Maybe you are talking about something else ... ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-30 09:36 Message: Logged In: YES user_id=764593 I suggest changing status to Pending Close - not a bug. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-30 09:34 Message: Logged In: YES user_id=764593 Looking at your example code (as best I can guess about indentation), it looks like module x <==> class X module x <==> class A ==> A's instance x ==> class X module x <==> class B ==> B's instance x ==> class X So the x instances can't go away until A and B do, which means at module cleanup. But when the module cleans up, it may well clean up X before A, so that A.x no longer has an active class, so that it can't find its __del__ method. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-30 09:22 Message: Logged In: YES user_id=764593 The funny interaction with modules is probably that the module retains a reference to the class (and vice versa), so the class can't go away until the module does -- and a module in sys.modules can't go away. The __del__ methods are not called if the interpreter can't decide which to call first. For example, if A.attr=B B.attr=A then A and B form a cycle (like the class and its defining module). If only one has a __del__ method, it gets called, but if both do, then python doesn't know which to call first, so it never calls either. You may have a cycle like module <==> class <==>instanceA \ <==>instanceB So that it can't decide whether to take care of instanceA or instanceB first. Or it might be that the __del__ methods actually are being called, but not until module teardown has begun, so they don't work right. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 20:08 Message: Logged In: YES user_id=835142 I used __del__ just to illustrate the problem. In real life application, X was a type defined in a C module and I've noticed that it's tp_dealloc is not called on instances assigned to class variables. BTW, what are the circumstances when __del__() methods are not called for objects that still exist when the interpreter exits? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-23 19:18 Message: Logged In: YES user_id=849994 There's also this sentence in the __del__ docs: """ It is not guaranteed that __del__() methods are called for objects that still exist when the interpreter exits. """ ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 18:54 Message: Logged In: YES user_id=835142 Yes, I've found that (using gc.get_referrers!), but this does not explain why A is not cleaned up when the program exits. Note that if I put class A definition inside a function, it does get cleaned up. Must be some funny interation between module and new-style class objects. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-23 18:45 Message: Logged In: YES user_id=849994 Note that new-style classes are always part of a reference cycle (you can find this out via gc.get_referrers). Therefore, they will not be deleted instantly, but only after gc collects them (you can trigger that via gc.collect). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 18:01 Message: Logged In: YES user_id=835142 It looks like the class object is not deleted alltogether: class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') del A Output: creating X('new') deleting X('new') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 From noreply at sourceforge.net Wed Aug 30 16:30:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 30 Aug 2006 07:30:40 -0700 Subject: [ python-Bugs-1545463 ] New-style classes fail to cleanup attributes Message-ID: Bugs item #1545463, was opened at 2006-08-23 14:24 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 Please note that this 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: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: New-style classes fail to cleanup attributes Initial Comment: > cat x.py class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') class B: x = X('old') > python x.py creating X('new') creating X('old') deleting X('old') Python 2.4.2 (#2, Jan 13 2006, 12:00:38) Python 2.6a0 (trunk:51513M, Aug 23 2006, 14:17:11) ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-30 10:30 Message: Logged In: YES user_id=764593 More precisely, it retains a reference to the module's __dict__ as its globals. At the moment, I'm not finding proof that this happens directly in the class, but it does happen in class methods -- including __del__. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-30 09:53 Message: Logged In: YES user_id=835142 Is it true that a class retains reference to the module? The '__module__' attribute is a string, not a reference to the module. Maybe you are talking about something else ... ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-30 09:36 Message: Logged In: YES user_id=764593 I suggest changing status to Pending Close - not a bug. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-30 09:34 Message: Logged In: YES user_id=764593 Looking at your example code (as best I can guess about indentation), it looks like module x <==> class X module x <==> class A ==> A's instance x ==> class X module x <==> class B ==> B's instance x ==> class X So the x instances can't go away until A and B do, which means at module cleanup. But when the module cleans up, it may well clean up X before A, so that A.x no longer has an active class, so that it can't find its __del__ method. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-08-30 09:22 Message: Logged In: YES user_id=764593 The funny interaction with modules is probably that the module retains a reference to the class (and vice versa), so the class can't go away until the module does -- and a module in sys.modules can't go away. The __del__ methods are not called if the interpreter can't decide which to call first. For example, if A.attr=B B.attr=A then A and B form a cycle (like the class and its defining module). If only one has a __del__ method, it gets called, but if both do, then python doesn't know which to call first, so it never calls either. You may have a cycle like module <==> class <==>instanceA \ <==>instanceB So that it can't decide whether to take care of instanceA or instanceB first. Or it might be that the __del__ methods actually are being called, but not until module teardown has begun, so they don't work right. ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 20:08 Message: Logged In: YES user_id=835142 I used __del__ just to illustrate the problem. In real life application, X was a type defined in a C module and I've noticed that it's tp_dealloc is not called on instances assigned to class variables. BTW, what are the circumstances when __del__() methods are not called for objects that still exist when the interpreter exits? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-23 19:18 Message: Logged In: YES user_id=849994 There's also this sentence in the __del__ docs: """ It is not guaranteed that __del__() methods are called for objects that still exist when the interpreter exits. """ ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 18:54 Message: Logged In: YES user_id=835142 Yes, I've found that (using gc.get_referrers!), but this does not explain why A is not cleaned up when the program exits. Note that if I put class A definition inside a function, it does get cleaned up. Must be some funny interation between module and new-style class objects. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-23 18:45 Message: Logged In: YES user_id=849994 Note that new-style classes are always part of a reference cycle (you can find this out via gc.get_referrers). Therefore, they will not be deleted instantly, but only after gc collects them (you can trigger that via gc.collect). ---------------------------------------------------------------------- Comment By: Alexander Belopolsky (belopolsky) Date: 2006-08-23 18:01 Message: Logged In: YES user_id=835142 It looks like the class object is not deleted alltogether: class X(object): def __init__(self, x): self.x = x print 'creating X(%r)' % x def __del__(self): print 'deleting X(%r)' % self.x class A(object): x = X('new') del A Output: creating X('new') deleting X('new') ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545463&group_id=5470 From noreply at sourceforge.net Wed Aug 30 20:44:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 30 Aug 2006 11:44:31 -0700 Subject: [ python-Bugs-1549499 ] bug in classlevel variabels Message-ID: Bugs item #1549499, was opened at 2006-08-30 20: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=1549499&group_id=5470 Please note that this 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: Thomas Dybdahl Ahle (thomasda) Assigned to: Nobody/Anonymous (nobody) Summary: bug in classlevel variabels Initial Comment: class A: js = [] def add (self, j): self.js.append(j) def clone (self): c = A() for j in self.js: c.add(j) return c a = A() b = a.clone() b.add(3) print a.js print b.js The above code should print "[]\n[3]", but instead it prints "[3]\n[3]"! It works as expected, if you change "js = []" to "def __init__ (self): self.js = []" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549499&group_id=5470 From noreply at sourceforge.net Wed Aug 30 21:28:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 30 Aug 2006 12:28:24 -0700 Subject: [ python-Bugs-1549499 ] bug in classlevel variabels Message-ID: Bugs item #1549499, was opened at 2006-08-30 18:44 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549499&group_id=5470 Please note that this 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: Thomas Dybdahl Ahle (thomasda) Assigned to: Nobody/Anonymous (nobody) Summary: bug in classlevel variabels Initial Comment: class A: js = [] def add (self, j): self.js.append(j) def clone (self): c = A() for j in self.js: c.add(j) return c a = A() b = a.clone() b.add(3) print a.js print b.js The above code should print "[]\n[3]", but instead it prints "[3]\n[3]"! It works as expected, if you change "js = []" to "def __init__ (self): self.js = []" ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-30 19:28 Message: Logged In: YES user_id=849994 This is not a bug. The "js" list exists in the class's namespace and exists only once, and if you don't rebind the name, "self.js" always refers to this. Therefore it is shared between instances. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549499&group_id=5470 From noreply at sourceforge.net Wed Aug 30 22:46:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 30 Aug 2006 13:46:52 -0700 Subject: [ python-Bugs-1549574 ] Pdb parser bug Message-ID: Bugs item #1549574, was opened at 2006-08-30 16:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549574&group_id=5470 Please note that this 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: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Pdb parser bug Initial Comment: >>> import pdb >>> pdb.set_trace() --Return-- > (1)()->None (Pdb) p ";;" *** SyntaxError: SyntaxError('EOL while scanning single-quoted string', ('', 1, 1, '"')) *** SyntaxError: EOL while scanning single-quoted string (, line 1) Still present in trunk:51513M ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549574&group_id=5470 From noreply at sourceforge.net Wed Aug 30 23:19:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 30 Aug 2006 14:19:33 -0700 Subject: [ python-Bugs-1549589 ] urlparse return exchanged values Message-ID: Bugs item #1549589, was opened at 2006-08-30 21: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=1549589&group_id=5470 Please note that this 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: Oscar Acena (oscarah) Assigned to: Nobody/Anonymous (nobody) Summary: urlparse return exchanged values Initial Comment: The urlparser module is used to split an url into 6 fields, acording to the pertinent spec. The fields are: - scheme - net location - path - params - query - frag id The netloc of http://www.google.es/index.html is: "www.google.es" and the path is "/index.html", ok? But if you try this: >>> urlparse("www.google.es") the answer is: ('', '', 'www.google.es', '', '', '') instead of ('', 'www.google.es', '', '', '', '') On the other hand, if you try this: >>> urlparse("http://www.google.es") the answer is: ('http', 'www.google.es', '', '', '', '') which is correct. The pytho header is: Python 2.4.4c0 (#2, Jul 30 2006, 15:43:58) [GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)] on linux2 and I downloaded the latest version of that lib (urlparse.py, at 2006 08 30) Thats all. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549589&group_id=5470 From noreply at sourceforge.net Thu Aug 31 07:43:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 30 Aug 2006 22:43:17 -0700 Subject: [ python-Bugs-1549589 ] urlparse return exchanged values Message-ID: Bugs item #1549589, was opened at 2006-08-30 21:19 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549589&group_id=5470 Please note that this 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: Duplicate Priority: 5 Submitted By: Oscar Acena (oscarah) Assigned to: Nobody/Anonymous (nobody) Summary: urlparse return exchanged values Initial Comment: The urlparser module is used to split an url into 6 fields, acording to the pertinent spec. The fields are: - scheme - net location - path - params - query - frag id The netloc of http://www.google.es/index.html is: "www.google.es" and the path is "/index.html", ok? But if you try this: >>> urlparse("www.google.es") the answer is: ('', '', 'www.google.es', '', '', '') instead of ('', 'www.google.es', '', '', '', '') On the other hand, if you try this: >>> urlparse("http://www.google.es") the answer is: ('http', 'www.google.es', '', '', '', '') which is correct. The pytho header is: Python 2.4.4c0 (#2, Jul 30 2006, 15:43:58) [GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)] on linux2 and I downloaded the latest version of that lib (urlparse.py, at 2006 08 30) Thats all. Thanks. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-08-31 05:43 Message: Logged In: YES user_id=849994 Duplicate of #754016. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549589&group_id=5470 From noreply at sourceforge.net Thu Aug 31 11:52:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 02:52:58 -0700 Subject: [ python-Bugs-1549589 ] urlparse return exchanged values Message-ID: Bugs item #1549589, was opened at 2006-08-30 21:19 Message generated for change (Comment added) made by oscarah You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549589&group_id=5470 Please note that this 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: Duplicate Priority: 5 Submitted By: Oscar Acena (oscarah) Assigned to: Nobody/Anonymous (nobody) Summary: urlparse return exchanged values Initial Comment: The urlparser module is used to split an url into 6 fields, acording to the pertinent spec. The fields are: - scheme - net location - path - params - query - frag id The netloc of http://www.google.es/index.html is: "www.google.es" and the path is "/index.html", ok? But if you try this: >>> urlparse("www.google.es") the answer is: ('', '', 'www.google.es', '', '', '') instead of ('', 'www.google.es', '', '', '', '') On the other hand, if you try this: >>> urlparse("http://www.google.es") the answer is: ('http', 'www.google.es', '', '', '', '') which is correct. The pytho header is: Python 2.4.4c0 (#2, Jul 30 2006, 15:43:58) [GCC 4.1.2 20060715 (prerelease) (Debian 4.1.1-9)] on linux2 and I downloaded the latest version of that lib (urlparse.py, at 2006 08 30) Thats all. Thanks. ---------------------------------------------------------------------- >Comment By: Oscar Acena (oscarah) Date: 2006-08-31 09:52 Message: Logged In: YES user_id=1587388 Sorry then! I look for it but i haven't found anything. Thanks for your time. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-08-31 05:43 Message: Logged In: YES user_id=849994 Duplicate of #754016. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1549589&group_id=5470 From noreply at sourceforge.net Thu Aug 31 22:34:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 31 Aug 2006 13:34:22 -0700 Subject: [ python-Bugs-1548371 ] filterwarnings('error') has no effect Message-ID: Bugs item #1548371, was opened at 2006-08-29 09:27 Message generated for change (Comment added) made by marienz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548371&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: filterwarnings('error') has no effect Initial Comment: Once a warning has already been issued, warnings.filterwarnings('error',...) will not cause an error to be raised. When the attached script is run, the warning is printed the first time thru the loop, but no error is raised the 2nd time thru. Likewise, warnings.filterwarnings('always',...) will not cause the warning to be printed again. ---------------------------------------------------------------------- Comment By: Marien Zwart (marienz) Date: 2006-08-31 22:34 Message: Logged In: YES user_id=857292 This is caused by the warnings module caching when a combination of message, Warning subclass and linenumber gets ignored and bypassing the search through the warning filters when that same combination occurs again. I think it is possible to avoid this problem while keeping the cache by keeping track of the "version" of the filters list (a simple integer that is incremented every time the filters list is modified through the functions in the warnings module) and including this in the key tuple warn_explicit uses to remember previous ignores. Old stuff would remain in the cache but that should not be a big problem (changes to the filters list should not be that common). Does this sound reasonable? If it does I'll see if I can produce a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548371&group_id=5470