From noreply at sourceforge.net Wed Nov 1 00:05:43 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Oct 2006 15:05:43 -0800 Subject: [ python-Bugs-1588287 ] python: Python/ast.c:541: seq_for_testlist: Assertion fails Message-ID: Bugs item #1588287, was opened at 2006-10-31 15:05 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588287&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tom Epperly (tepperly) Assigned to: Nobody/Anonymous (nobody) Summary: python: Python/ast.c:541: seq_for_testlist: Assertion fails Initial Comment: I 1. downloaded Python 2.5 final wget 'http://www.python.org/ftp/python/2.5/Python-2.5.tar.bz2' 2. edited Python-2.5/Objects/obmalloc.c to uncomment the #define Py_USING_MEMORY_DEBUGGER line (I plan to run valgrind on this installation of Python) 3. ./configure --without-pymalloc --with-pydebug --prefix=/somewhere/python2_5 4. make and then "make install" 5. next I downloaded and extracted numpy-1.0.tar.gz from Sourceforge: http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103 When I try to run the setup.py for numpy-1.0, I get an assertion failure. [epperly at tux163 numpy-1.0]$ python setup.py install Running from numpy source directory. python: Python/ast.c:541: seq_for_testlist: Assertion `((n)->n_type) == 326 || ((n)->n_type) == 318 || ((n)->n_type) == 319 || ((n)->n_type) == 300' failed. Abort [epperly at tux163 numpy-1.0]$ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588287&group_id=5470 From noreply at sourceforge.net Wed Nov 1 00:16:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 31 Oct 2006 15:16:26 -0800 Subject: [ python-Bugs-1588287 ] python: Python/ast.c:541: seq_for_testlist: Assertion fails Message-ID: Bugs item #1588287, was opened at 2006-10-31 15:05 Message generated for change (Comment added) made by tepperly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588287&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tom Epperly (tepperly) Assigned to: Nobody/Anonymous (nobody) Summary: python: Python/ast.c:541: seq_for_testlist: Assertion fails Initial Comment: I 1. downloaded Python 2.5 final wget 'http://www.python.org/ftp/python/2.5/Python-2.5.tar.bz2' 2. edited Python-2.5/Objects/obmalloc.c to uncomment the #define Py_USING_MEMORY_DEBUGGER line (I plan to run valgrind on this installation of Python) 3. ./configure --without-pymalloc --with-pydebug --prefix=/somewhere/python2_5 4. make and then "make install" 5. next I downloaded and extracted numpy-1.0.tar.gz from Sourceforge: http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103 When I try to run the setup.py for numpy-1.0, I get an assertion failure. [epperly at tux163 numpy-1.0]$ python setup.py install Running from numpy source directory. python: Python/ast.c:541: seq_for_testlist: Assertion `((n)->n_type) == 326 || ((n)->n_type) == 318 || ((n)->n_type) == 319 || ((n)->n_type) == 300' failed. Abort [epperly at tux163 numpy-1.0]$ ---------------------------------------------------------------------- >Comment By: Tom Epperly (tepperly) Date: 2006-10-31 15:16 Message: Logged In: YES user_id=94539 If I drop the --with-pydebug from the configure line, it runs the NumPy's setup.py without error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588287&group_id=5470 From noreply at sourceforge.net Wed Nov 1 23:47:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Nov 2006 14:47:06 -0800 Subject: [ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not work Message-ID: Bugs item #1579029, was opened at 2006-10-17 17:03 Message generated for change (Comment added) made by thurnerrupert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Martin v. L?wis (loewis) Summary: --disable-sunaudiodev --disable-tk does not work Initial Comment: trying to disable sunaudiodev and tk does not really work in solaris. ./configure --prefix=/usr/local/Python-2.5 --enable- shared --disable-sunaudiodev --disable-tk building 'sunaudiodev' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/sunaudiodev.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/sunaudiodev.o /usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: sun/audioio.h: No such file or directory building '_tkinter' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -DWITH_APPINIT=1 - I/usr/openwin/include -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/_tkinter.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/_tkinter.o In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:96:23: X11/Xlib.h: No such file or directory In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:572: error: syntax error before "Window" /usr/local/include/tk.h:572: error: `Window' declared as function returning a function /usr/local/include/tk.h:575: error: syntax error before "XEvent" /usr/local/include/tk.h:584: error: syntax error before "Tk_ClassCreateProc" /usr/local/include/tk.h:592: error: syntax error before '}' token /usr/local/include/tk.h:678: error: syntax error before "Bool" is it possible to correct this or state clearly in the configure options how to disable it correctly? we also checked the Modules/Setup and both seems commented. ---------------------------------------------------------------------- >Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:47 Message: Logged In: YES user_id=1597584 because there is a compilation error with both. sunaudio.h seems not to exist on our server, and tk gives other compilation errors. and i have no idea why i would need these modules on our server. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-17 17:43 Message: Logged In: YES user_id=21627 I fail to see a bug here. What makes you think --disable-sunaudiodev --disable-tk exist? ./configure --help does not claim they do. In fact, it is not possible to disable modules. Why do you want that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 From noreply at sourceforge.net Wed Nov 1 23:49:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Nov 2006 14:49:17 -0800 Subject: [ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not work Message-ID: Bugs item #1579029, was opened at 2006-10-17 17:03 Message generated for change (Comment added) made by thurnerrupert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Martin v. L?wis (loewis) Summary: --disable-sunaudiodev --disable-tk does not work Initial Comment: trying to disable sunaudiodev and tk does not really work in solaris. ./configure --prefix=/usr/local/Python-2.5 --enable- shared --disable-sunaudiodev --disable-tk building 'sunaudiodev' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/sunaudiodev.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/sunaudiodev.o /usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: sun/audioio.h: No such file or directory building '_tkinter' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -DWITH_APPINIT=1 - I/usr/openwin/include -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/_tkinter.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/_tkinter.o In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:96:23: X11/Xlib.h: No such file or directory In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:572: error: syntax error before "Window" /usr/local/include/tk.h:572: error: `Window' declared as function returning a function /usr/local/include/tk.h:575: error: syntax error before "XEvent" /usr/local/include/tk.h:584: error: syntax error before "Tk_ClassCreateProc" /usr/local/include/tk.h:592: error: syntax error before '}' token /usr/local/include/tk.h:678: error: syntax error before "Bool" is it possible to correct this or state clearly in the configure options how to disable it correctly? we also checked the Modules/Setup and both seems commented. ---------------------------------------------------------------------- >Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:49 Message: Logged In: YES user_id=1597584 and what does that mean? Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:47 Message: Logged In: YES user_id=1597584 because there is a compilation error with both. sunaudio.h seems not to exist on our server, and tk gives other compilation errors. and i have no idea why i would need these modules on our server. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-17 17:43 Message: Logged In: YES user_id=21627 I fail to see a bug here. What makes you think --disable-sunaudiodev --disable-tk exist? ./configure --help does not claim they do. In fact, it is not possible to disable modules. Why do you want that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 From noreply at sourceforge.net Thu Nov 2 00:31:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Nov 2006 15:31:36 -0800 Subject: [ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not work Message-ID: Bugs item #1579029, was opened at 2006-10-17 17:03 Message generated for change (Comment added) made by thurnerrupert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Martin v. L?wis (loewis) Summary: --disable-sunaudiodev --disable-tk does not work Initial Comment: trying to disable sunaudiodev and tk does not really work in solaris. ./configure --prefix=/usr/local/Python-2.5 --enable- shared --disable-sunaudiodev --disable-tk building 'sunaudiodev' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/sunaudiodev.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/sunaudiodev.o /usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: sun/audioio.h: No such file or directory building '_tkinter' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -DWITH_APPINIT=1 - I/usr/openwin/include -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/_tkinter.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/_tkinter.o In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:96:23: X11/Xlib.h: No such file or directory In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:572: error: syntax error before "Window" /usr/local/include/tk.h:572: error: `Window' declared as function returning a function /usr/local/include/tk.h:575: error: syntax error before "XEvent" /usr/local/include/tk.h:584: error: syntax error before "Tk_ClassCreateProc" /usr/local/include/tk.h:592: error: syntax error before '}' token /usr/local/include/tk.h:678: error: syntax error before "Bool" is it possible to correct this or state clearly in the configure options how to disable it correctly? we also checked the Modules/Setup and both seems commented. ---------------------------------------------------------------------- >Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-02 00:31 Message: Logged In: YES user_id=1597584 and there is no X on the server. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:49 Message: Logged In: YES user_id=1597584 and what does that mean? Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:47 Message: Logged In: YES user_id=1597584 because there is a compilation error with both. sunaudio.h seems not to exist on our server, and tk gives other compilation errors. and i have no idea why i would need these modules on our server. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-17 17:43 Message: Logged In: YES user_id=21627 I fail to see a bug here. What makes you think --disable-sunaudiodev --disable-tk exist? ./configure --help does not claim they do. In fact, it is not possible to disable modules. Why do you want that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 From noreply at sourceforge.net Thu Nov 2 01:02:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Nov 2006 16:02:40 -0800 Subject: [ python-Bugs-1588975 ] string subscripting not working on a specific string Message-ID: Bugs item #1588975, was opened at 2006-11-02 00: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=1588975&group_id=5470 Please note that this message 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 Private: No Submitted By: Dan Aronson (danaronson) Assigned to: Nobody/Anonymous (nobody) Summary: string subscripting not working on a specific string Initial Comment: on both python2.4 and 2.5, I'm getting incorrect results while looking at a slice of a particular string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588975&group_id=5470 From noreply at sourceforge.net Thu Nov 2 01:06:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Nov 2006 16:06:44 -0800 Subject: [ python-Bugs-1588975 ] string subscripting not working on a specific string Message-ID: Bugs item #1588975, was opened at 2006-11-02 00:02 Message generated for change (Comment added) made by danaronson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588975&group_id=5470 Please note that this message 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 Private: No Submitted By: Dan Aronson (danaronson) Assigned to: Nobody/Anonymous (nobody) Summary: string subscripting not working on a specific string Initial Comment: on both python2.4 and 2.5, I'm getting incorrect results while looking at a slice of a particular string. ---------------------------------------------------------------------- >Comment By: Dan Aronson (danaronson) Date: 2006-11-02 00:06 Message: Logged In: YES user_id=899862 ignore this, PBCAK (problem between chair and keyboard) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588975&group_id=5470 From noreply at sourceforge.net Thu Nov 2 06:40:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Nov 2006 21:40:21 -0800 Subject: [ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not work Message-ID: Bugs item #1579029, was opened at 2006-10-17 17:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Martin v. L?wis (loewis) Summary: --disable-sunaudiodev --disable-tk does not work Initial Comment: trying to disable sunaudiodev and tk does not really work in solaris. ./configure --prefix=/usr/local/Python-2.5 --enable- shared --disable-sunaudiodev --disable-tk building 'sunaudiodev' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/sunaudiodev.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/sunaudiodev.o /usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: sun/audioio.h: No such file or directory building '_tkinter' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -DWITH_APPINIT=1 - I/usr/openwin/include -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/_tkinter.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/_tkinter.o In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:96:23: X11/Xlib.h: No such file or directory In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:572: error: syntax error before "Window" /usr/local/include/tk.h:572: error: `Window' declared as function returning a function /usr/local/include/tk.h:575: error: syntax error before "XEvent" /usr/local/include/tk.h:584: error: syntax error before "Tk_ClassCreateProc" /usr/local/include/tk.h:592: error: syntax error before '}' token /usr/local/include/tk.h:678: error: syntax error before "Bool" is it possible to correct this or state clearly in the configure options how to disable it correctly? we also checked the Modules/Setup and both seems commented. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-02 06:40 Message: Logged In: YES user_id=21627 Re: enable/disable: What makes you think "sunaudiodev" and "tk" are valid values for "FEATURE"? configure --help lists the valid values for FEATURE, namely universalsdk, framework, shared, profiling, toolbox-glue, ipv6, and unicode. Re: there is a compilation error. Sure, an error is reported. However, compilation should not fail because of that. Instead, compilation should complete successfully, and just end up not building these modules. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-02 00:31 Message: Logged In: YES user_id=1597584 and there is no X on the server. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:49 Message: Logged In: YES user_id=1597584 and what does that mean? Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:47 Message: Logged In: YES user_id=1597584 because there is a compilation error with both. sunaudio.h seems not to exist on our server, and tk gives other compilation errors. and i have no idea why i would need these modules on our server. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-17 17:43 Message: Logged In: YES user_id=21627 I fail to see a bug here. What makes you think --disable-sunaudiodev --disable-tk exist? ./configure --help does not claim they do. In fact, it is not possible to disable modules. Why do you want that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 From noreply at sourceforge.net Thu Nov 2 06:55:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Nov 2006 21:55:11 -0800 Subject: [ python-Bugs-1589074 ] Unneeded constants left during optimization Message-ID: Bugs item #1589074, was opened at 2006-11-02 01:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589074&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel (kamek) Assigned to: Nobody/Anonymous (nobody) Summary: Unneeded constants left during optimization Initial Comment: At some point, when generating the bytecode, the parser/compiler pre-calculates operations on constants. However, the old values, which are often not needed anymore in the constants, are left there as garbage. To keep this description from being lengthy, I'm attaching a text file with several simple demonstrations that serve as testcases. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589074&group_id=5470 From noreply at sourceforge.net Thu Nov 2 06:58:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Nov 2006 21:58:00 -0800 Subject: [ python-Bugs-1589074 ] Unneeded constants left during optimization Message-ID: Bugs item #1589074, was opened at 2006-11-02 01:55 Message generated for change (Comment added) made by kamek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589074&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel (kamek) Assigned to: Nobody/Anonymous (nobody) Summary: Unneeded constants left during optimization Initial Comment: At some point, when generating the bytecode, the parser/compiler pre-calculates operations on constants. However, the old values, which are often not needed anymore in the constants, are left there as garbage. To keep this description from being lengthy, I'm attaching a text file with several simple demonstrations that serve as testcases. ---------------------------------------------------------------------- >Comment By: Daniel (kamek) Date: 2006-11-02 01:58 Message: Logged In: YES user_id=539453 Sorry, I rushed and missed the File Description field. Should be "Interactive interpreter testcases". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589074&group_id=5470 From noreply at sourceforge.net Thu Nov 2 16:18:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Nov 2006 07:18:56 -0800 Subject: [ python-Bugs-1589328 ] ctypes XXX - add a crossref, at least Message-ID: Bugs item #1589328, was opened at 2006-11-02 10: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=1589328&group_id=5470 Please note that this 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 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: ctypes XXX - add a crossref, at least Initial Comment: The python library reference section 14.14.2.9 (ctypes Arrays and Pointers) is an XXX. Until it is filled out, please at least add a cross reference to 14.14.1.13 (array tutorial) and 14.14.1.14 (pointer tutorial) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589328&group_id=5470 From noreply at sourceforge.net Thu Nov 2 17:16:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Nov 2006 08:16:01 -0800 Subject: [ python-Bugs-1588975 ] string subscripting not working on a specific string Message-ID: Bugs item #1588975, was opened at 2006-11-02 00:02 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588975&group_id=5470 Please note that this message 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 Private: No Submitted By: Dan Aronson (danaronson) Assigned to: Nobody/Anonymous (nobody) Summary: string subscripting not working on a specific string Initial Comment: on both python2.4 and 2.5, I'm getting incorrect results while looking at a slice of a particular string. ---------------------------------------------------------------------- Comment By: Dan Aronson (danaronson) Date: 2006-11-02 00:06 Message: Logged In: YES user_id=899862 ignore this, PBCAK (problem between chair and keyboard) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588975&group_id=5470 From noreply at sourceforge.net Thu Nov 2 17:18:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Nov 2006 08:18:29 -0800 Subject: [ python-Bugs-1576657 ] dict keyerror formatting and tuples Message-ID: Bugs item #1576657, was opened at 2006-10-13 16:00 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576657&group_id=5470 Please note that this message 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 Private: No Submitted By: M.-A. Lemburg (lemburg) >Assigned to: Georg Brandl (gbrandl) Summary: dict keyerror formatting and tuples Initial Comment: Probably just a minor glitch, but one which caused me half an hour to track down: >>> d = {1:'x'} >>> v = (1,) >>> d[v] Traceback (most recent call last): File "", line 1, in KeyError: 1 Note the formatting of the error message. It reads '1', not '(1,)' as you would expect. The example is constructed. In the code I was debugging, I didn't know that v was a tuple and thought it was the integer 1 - so the KeyError itself was somewhat puzzling. Only after printing the key I found that the lookup failed due to a type error. This happens in Python 2.4 and 2.5. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-02 16:18 Message: Logged In: YES user_id=849994 Patch was committed as rev. 52535/6. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-10-14 07:16 Message: Logged In: YES user_id=849994 This is because a tuple as exception "argument" is automatically unpacked as the arguments on NormalizeException. Attaching patch that wraps all KeyErrors from dictionaries in a tuple. (There may be other objects and exceptions where this must be handled) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576657&group_id=5470 From noreply at sourceforge.net Thu Nov 2 20:56:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Nov 2006 11:56:06 -0800 Subject: [ python-Bugs-1589328 ] ctypes XXX - add a crossref, at least Message-ID: Bugs item #1589328, was opened at 2006-11-02 16:18 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589328&group_id=5470 Please note that this 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 Private: No Submitted By: Jim Jewett (jimjjewett) >Assigned to: Thomas Heller (theller) Summary: ctypes XXX - add a crossref, at least Initial Comment: The python library reference section 14.14.2.9 (ctypes Arrays and Pointers) is an XXX. Until it is filled out, please at least add a cross reference to 14.14.1.13 (array tutorial) and 14.14.1.14 (pointer tutorial) ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-11-02 20:56 Message: Logged In: YES user_id=11105 Fixed in trunk, rev 52588, and release25-maint, rev 52589. Note that the ctypes docs are maintained in reST format, and the result is what the toolchain produces: "Not yet written - please see section 14.14.1, pointers and section 14.14.1, arrays in the tutorial." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589328&group_id=5470 From noreply at sourceforge.net Thu Nov 2 21:10:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Nov 2006 12:10:08 -0800 Subject: [ python-Bugs-1589480 ] urllib2 does local import of tokenize.py Message-ID: Bugs item #1589480, was opened at 2006-11-02 12: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=1589480&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Daniel Farina (drfarina) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 does local import of tokenize.py Initial Comment: urllib2 may do a relative import of tokenize.py, which can cause it to function abnormally when the user has a file named "tokenizer.py" in the directory as a script that utilizes urllib2. The attached tarball has a shell script called "showme.sh" that will give standard input to afile.py, which contains two import statements and nothing else. Code in the neighboring tokenize.py will be executed, resulting in printing those lines to standard output. Expected behavior: no code in tokenize.py should be executed. Reproducible on Ubuntu 6.10 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589480&group_id=5470 From noreply at sourceforge.net Thu Nov 2 21:11:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Nov 2006 12:11:01 -0800 Subject: [ python-Bugs-1589480 ] urllib2 does local import of tokenize.py Message-ID: Bugs item #1589480, was opened at 2006-11-02 12:10 Message generated for change (Comment added) made by drfarina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589480&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Daniel Farina (drfarina) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 does local import of tokenize.py Initial Comment: urllib2 may do a relative import of tokenize.py, which can cause it to function abnormally when the user has a file named "tokenizer.py" in the directory as a script that utilizes urllib2. The attached tarball has a shell script called "showme.sh" that will give standard input to afile.py, which contains two import statements and nothing else. Code in the neighboring tokenize.py will be executed, resulting in printing those lines to standard output. Expected behavior: no code in tokenize.py should be executed. Reproducible on Ubuntu 6.10 ---------------------------------------------------------------------- >Comment By: Daniel Farina (drfarina) Date: 2006-11-02 12:11 Message: Logged In: YES user_id=425987 Typo in the above: "tokenizer.py" should just be "tokenize.py" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589480&group_id=5470 From noreply at sourceforge.net Thu Nov 2 21:16:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Nov 2006 12:16:36 -0800 Subject: [ python-Bugs-1589480 ] urllib2 does local import of tokenize.py Message-ID: Bugs item #1589480, was opened at 2006-11-02 12:10 Message generated for change (Comment added) made by drfarina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589480&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Daniel Farina (drfarina) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 does local import of tokenize.py Initial Comment: urllib2 may do a relative import of tokenize.py, which can cause it to function abnormally when the user has a file named "tokenizer.py" in the directory as a script that utilizes urllib2. The attached tarball has a shell script called "showme.sh" that will give standard input to afile.py, which contains two import statements and nothing else. Code in the neighboring tokenize.py will be executed, resulting in printing those lines to standard output. Expected behavior: no code in tokenize.py should be executed. Reproducible on Ubuntu 6.10 ---------------------------------------------------------------------- >Comment By: Daniel Farina (drfarina) Date: 2006-11-02 12:16 Message: Logged In: YES user_id=425987 Yet another typo: the script is called "show.sh" It's the only shell script in there, so no fear. ---------------------------------------------------------------------- Comment By: Daniel Farina (drfarina) Date: 2006-11-02 12:11 Message: Logged In: YES user_id=425987 Typo in the above: "tokenizer.py" should just be "tokenize.py" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589480&group_id=5470 From noreply at sourceforge.net Thu Nov 2 22:02:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 02 Nov 2006 13:02:56 -0800 Subject: [ python-Bugs-1582742 ] Python is dumping core after the test test_ctypes Message-ID: Bugs item #1582742, was opened at 2006-10-23 11:42 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582742&group_id=5470 Please note that this message 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 Private: No Submitted By: shashi (shashikala) Assigned to: Thomas Heller (theller) Summary: Python is dumping core after the test test_ctypes Initial Comment: Hi , Iam building Python-2.5 on HPUX Itanium. The compilation is done without any error, but while testing the same using gmake test it is dumping core telling "Segementation Fault" after the test test_ctypes. Please help me in resolving the above issue.Iam attaching the output of gmake test. Thanks in advance, ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-11-02 22:02 Message: Logged In: YES user_id=11105 Neal, I see no connection between the code that you show and the stack dump. For the failure when importing ctypes.test.test_cfuncs it seems that a library (?) is missing that _ctypes_test.so requires. Any idea? (I know that HP offers shell access to HPUX boxes, but I hesitate to try that out...). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-29 03:05 Message: Logged In: YES user_id=33168 This is the code that crashes: from ctypes import * print cast(c_void_p(0), POINTER(c_int)) *** #0 ffi_call_unix+0x20 () at trunk/Modules/_ctypes/libffi/src/ia64/unix.S:63 #1 0x2000000079194d30:0 in ffi_call (cif=0x7fffe020, fn=0x7913a860, rvalue=0x7fffe090, avalue=0x7fffe070) at trunk/Modules/_ctypes/libffi/src/ia64/ffi.c:372 #2 0x20000000791762f0:0 in _call_function_pointer (flags=4101, pProc=0x7913a860, avalues=0x7fffe070, atypes=0x7fffe050, restype=0x40081de8, resmem=0x7fffe090, argcount=3) at trunk/Modules/_ctypes/callproc.c:665 #3 0x20000000791781d0:0 in _CallProc (pProc=0x7913a860, argtuple=0x401cdd78, flags=4101, argtypes=0x401ef7b8, restype=0x400eacd8, checker=0x0) at trunk/Modules/_ctypes/callproc.c:1001 #4 0x2000000079165350:0 in CFuncPtr_call (self=0x4007abe8, inargs=0x401cdd78, kwds=0x0) at trunk/Modules/_ctypes/_ctypes.c:3364 *** Also note there are a bunch of errors like this: Warning: could not import ctypes.test.test_cfuncs: Unsatisfied code symbol '__divsf3' in load module 'trunk/build/lib.hp-ux-B.11.23-ia64-2.6/_ctypes_test.so'. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-25 10:41 Message: Logged In: YES user_id=21627 You will need to run Python in a debugger and find out where it crashes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582742&group_id=5470 From noreply at sourceforge.net Fri Nov 3 09:48:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Nov 2006 00:48:45 -0800 Subject: [ python-Bugs-1588287 ] python: Python/ast.c:541: seq_for_testlist: Assertion fails Message-ID: Bugs item #1588287, was opened at 2006-10-31 15:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588287&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tom Epperly (tepperly) Assigned to: Nobody/Anonymous (nobody) Summary: python: Python/ast.c:541: seq_for_testlist: Assertion fails Initial Comment: I 1. downloaded Python 2.5 final wget 'http://www.python.org/ftp/python/2.5/Python-2.5.tar.bz2' 2. edited Python-2.5/Objects/obmalloc.c to uncomment the #define Py_USING_MEMORY_DEBUGGER line (I plan to run valgrind on this installation of Python) 3. ./configure --without-pymalloc --with-pydebug --prefix=/somewhere/python2_5 4. make and then "make install" 5. next I downloaded and extracted numpy-1.0.tar.gz from Sourceforge: http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103 When I try to run the setup.py for numpy-1.0, I get an assertion failure. [epperly at tux163 numpy-1.0]$ python setup.py install Running from numpy source directory. python: Python/ast.c:541: seq_for_testlist: Assertion `((n)->n_type) == 326 || ((n)->n_type) == 318 || ((n)->n_type) == 319 || ((n)->n_type) == 300' failed. Abort [epperly at tux163 numpy-1.0]$ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-03 00:48 Message: Logged In: YES user_id=33168 That's weird. This is definitely a non-standard configuration, but it should work. I don't understand why it would matter if using pydebug or not. It shouldn't make a diff. It would take quite a while to setup the same config. Can you debug this further? Either find the python code that's causing the problem or the problem in the C code? My guess is the only way this could happen based on the grammar is a list inside backticks ``. But I couldn't reproduce it. ---------------------------------------------------------------------- Comment By: Tom Epperly (tepperly) Date: 2006-10-31 15:16 Message: Logged In: YES user_id=94539 If I drop the --with-pydebug from the configure line, it runs the NumPy's setup.py without error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588287&group_id=5470 From noreply at sourceforge.net Fri Nov 3 12:56:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Nov 2006 03:56:51 -0800 Subject: [ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not work Message-ID: Bugs item #1579029, was opened at 2006-10-17 17:03 Message generated for change (Comment added) made by thurnerrupert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Martin v. L?wis (loewis) Summary: --disable-sunaudiodev --disable-tk does not work Initial Comment: trying to disable sunaudiodev and tk does not really work in solaris. ./configure --prefix=/usr/local/Python-2.5 --enable- shared --disable-sunaudiodev --disable-tk building 'sunaudiodev' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/sunaudiodev.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/sunaudiodev.o /usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: sun/audioio.h: No such file or directory building '_tkinter' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -DWITH_APPINIT=1 - I/usr/openwin/include -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/_tkinter.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/_tkinter.o In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:96:23: X11/Xlib.h: No such file or directory In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:572: error: syntax error before "Window" /usr/local/include/tk.h:572: error: `Window' declared as function returning a function /usr/local/include/tk.h:575: error: syntax error before "XEvent" /usr/local/include/tk.h:584: error: syntax error before "Tk_ClassCreateProc" /usr/local/include/tk.h:592: error: syntax error before '}' token /usr/local/include/tk.h:678: error: syntax error before "Bool" is it possible to correct this or state clearly in the configure options how to disable it correctly? we also checked the Modules/Setup and both seems commented. ---------------------------------------------------------------------- >Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-03 12:56 Message: Logged In: YES user_id=1597584 what do you suggest then to convince the build not to build it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-02 06:40 Message: Logged In: YES user_id=21627 Re: enable/disable: What makes you think "sunaudiodev" and "tk" are valid values for "FEATURE"? configure --help lists the valid values for FEATURE, namely universalsdk, framework, shared, profiling, toolbox-glue, ipv6, and unicode. Re: there is a compilation error. Sure, an error is reported. However, compilation should not fail because of that. Instead, compilation should complete successfully, and just end up not building these modules. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-02 00:31 Message: Logged In: YES user_id=1597584 and there is no X on the server. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:49 Message: Logged In: YES user_id=1597584 and what does that mean? Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:47 Message: Logged In: YES user_id=1597584 because there is a compilation error with both. sunaudio.h seems not to exist on our server, and tk gives other compilation errors. and i have no idea why i would need these modules on our server. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-17 17:43 Message: Logged In: YES user_id=21627 I fail to see a bug here. What makes you think --disable-sunaudiodev --disable-tk exist? ./configure --help does not claim they do. In fact, it is not possible to disable modules. Why do you want that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 From noreply at sourceforge.net Fri Nov 3 17:20:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Nov 2006 08:20:30 -0800 Subject: [ python-Bugs-1589480 ] urllib2 does local import of tokenize.py Message-ID: Bugs item #1589480, was opened at 2006-11-02 20:10 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589480&group_id=5470 Please note that this message will contain 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: Pending Resolution: None Priority: 5 Private: No Submitted By: Daniel Farina (drfarina) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 does local import of tokenize.py Initial Comment: urllib2 may do a relative import of tokenize.py, which can cause it to function abnormally when the user has a file named "tokenizer.py" in the directory as a script that utilizes urllib2. The attached tarball has a shell script called "showme.sh" that will give standard input to afile.py, which contains two import statements and nothing else. Code in the neighboring tokenize.py will be executed, resulting in printing those lines to standard output. Expected behavior: no code in tokenize.py should be executed. Reproducible on Ubuntu 6.10 ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-03 16:20 Message: Logged In: YES user_id=849994 I can't reproduce that here with your example code, and there's also no mention of "tokenize" in urllib2.py. In any case, "import tokenize" is not a relative import, and it's the only way a standard library module can import another standard library module. That this can interfere with user-defined modules is known and must be worked around by not naming them like builtin modules. ---------------------------------------------------------------------- Comment By: Daniel Farina (drfarina) Date: 2006-11-02 20:16 Message: Logged In: YES user_id=425987 Yet another typo: the script is called "show.sh" It's the only shell script in there, so no fear. ---------------------------------------------------------------------- Comment By: Daniel Farina (drfarina) Date: 2006-11-02 20:11 Message: Logged In: YES user_id=425987 Typo in the above: "tokenizer.py" should just be "tokenize.py" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589480&group_id=5470 From noreply at sourceforge.net Fri Nov 3 17:44:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Nov 2006 08:44:21 -0800 Subject: [ python-Bugs-1590036 ] __getattr__ = getattr crash Message-ID: Bugs item #1590036, was opened at 2006-11-03 10:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590036&group_id=5470 Please note that this message 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 Private: No Submitted By: Brian Harring (ferringb) Assigned to: Nobody/Anonymous (nobody) Summary: __getattr__ = getattr crash Initial Comment: class c(object):__getattr__ = getattr c().spam Now granted... it's retarded to attempt this. But out of curiousity, I decided to be the retard, and noticed the interpreter crashes instead of triggering a RuntimeError for recursion. As far as I know, getattr is instrumented with Py_EnterRecursiveCall and Py_LEaveRecursiveCall... so a bit curious as to how it's occuring. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590036&group_id=5470 From noreply at sourceforge.net Fri Nov 3 17:45:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Nov 2006 08:45:55 -0800 Subject: [ python-Bugs-1574217 ] isinstance swallows exceptions Message-ID: Bugs item #1574217, was opened at 2006-10-09 21:55 Message generated for change (Settings changed) made by ferringb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574217&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Brian Harring (ferringb) Assigned to: Nobody/Anonymous (nobody) Summary: isinstance swallows exceptions Initial Comment: Attached is a simple example; yes, a bit contrived, but it's exactly what bit me in the ass for a week or two :) nestled within abstract.c's recursive_isinstance, is this lil nugget- icls = PyObject_GetAttr(inst, __class__); if (icls == NULL) { PyErr_Clear(); retval = 0; } else { No surrouding comments to indicate *why* it's swallowing exceptions, but best explanation I've heard was that it was attempting to swallow just AttributeError... which would make sense. So the question is, whats the purpose of it swallowing exceptions there? Bad form of AttributeError catching, or some unstated reason? ---------------------------------------------------------------------- Comment By: Brian Harring (ferringb) Date: 2006-10-09 21:56 Message: Logged In: YES user_id=874085 addition note; this is both 2.5 and 2.4, probably stretches bit further back also. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574217&group_id=5470 From noreply at sourceforge.net Fri Nov 3 18:39:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Nov 2006 09:39:53 -0800 Subject: [ python-Bugs-1590068 ] Error piping output between scripts on Windows Message-ID: Bugs item #1590068, was opened at 2006-11-03 19: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=1590068&group_id=5470 Please note that this message 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 Private: No Submitted By: Andrei (andrei1) Assigned to: Nobody/Anonymous (nobody) Summary: Error piping output between scripts on Windows Initial Comment: I created 2 programs, one writes to stdout, the other reads stdin: c:\>script1.py | script2.py Python spits out an error looking like the following: "IOError: [Errno 9] Bad file descriptor" This does not happen in Python 2.4.4, only in Python 2.5 Regards ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590068&group_id=5470 From noreply at sourceforge.net Fri Nov 3 19:26:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Nov 2006 10:26:23 -0800 Subject: [ python-Bugs-1589480 ] urllib2 does local import of tokenize.py Message-ID: Bugs item #1589480, was opened at 2006-11-02 12:10 Message generated for change (Comment added) made by drfarina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589480&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Daniel Farina (drfarina) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 does local import of tokenize.py Initial Comment: urllib2 may do a relative import of tokenize.py, which can cause it to function abnormally when the user has a file named "tokenizer.py" in the directory as a script that utilizes urllib2. The attached tarball has a shell script called "showme.sh" that will give standard input to afile.py, which contains two import statements and nothing else. Code in the neighboring tokenize.py will be executed, resulting in printing those lines to standard output. Expected behavior: no code in tokenize.py should be executed. Reproducible on Ubuntu 6.10 ---------------------------------------------------------------------- >Comment By: Daniel Farina (drfarina) Date: 2006-11-03 10:26 Message: Logged In: YES user_id=425987 I have a fresh Ubuntu Edgy install (although my home directory is quite old and persistent). I have installed the Python 2.5 package, but am not using it in this case. You are correct, urllib2 doesn't contain the import. I still get the behavior on my machine. On my machine, the following interaction takes place: fdr at Tenacity:~/urllib2_bug$ ls afile.py show.sh tokenize.py tokenize.pyc fdr at Tenacity:~/urllib2_bug$ ./show.sh import sys import urllib2 fdr at Tenacity:~/urllib2_bug$ more show.sh #!/bin/sh cat afile.py | python afile.py fdr at Tenacity:~/urllib2_bug$ more afile.py import sys import urllib2 fdr at Tenacity:~/urllib2_bug$ As we can see from the contents of afile.py, it shouldn't be printing anything. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-03 08:20 Message: Logged In: YES user_id=849994 I can't reproduce that here with your example code, and there's also no mention of "tokenize" in urllib2.py. In any case, "import tokenize" is not a relative import, and it's the only way a standard library module can import another standard library module. That this can interfere with user-defined modules is known and must be worked around by not naming them like builtin modules. ---------------------------------------------------------------------- Comment By: Daniel Farina (drfarina) Date: 2006-11-02 12:16 Message: Logged In: YES user_id=425987 Yet another typo: the script is called "show.sh" It's the only shell script in there, so no fear. ---------------------------------------------------------------------- Comment By: Daniel Farina (drfarina) Date: 2006-11-02 12:11 Message: Logged In: YES user_id=425987 Typo in the above: "tokenizer.py" should just be "tokenize.py" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589480&group_id=5470 From noreply at sourceforge.net Fri Nov 3 19:58:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Nov 2006 10:58:26 -0800 Subject: [ python-Bugs-1588287 ] python: Python/ast.c:541: seq_for_testlist: Assertion fails Message-ID: Bugs item #1588287, was opened at 2006-10-31 15:05 Message generated for change (Comment added) made by tepperly You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588287&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tom Epperly (tepperly) Assigned to: Nobody/Anonymous (nobody) Summary: python: Python/ast.c:541: seq_for_testlist: Assertion fails Initial Comment: I 1. downloaded Python 2.5 final wget 'http://www.python.org/ftp/python/2.5/Python-2.5.tar.bz2' 2. edited Python-2.5/Objects/obmalloc.c to uncomment the #define Py_USING_MEMORY_DEBUGGER line (I plan to run valgrind on this installation of Python) 3. ./configure --without-pymalloc --with-pydebug --prefix=/somewhere/python2_5 4. make and then "make install" 5. next I downloaded and extracted numpy-1.0.tar.gz from Sourceforge: http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103 When I try to run the setup.py for numpy-1.0, I get an assertion failure. [epperly at tux163 numpy-1.0]$ python setup.py install Running from numpy source directory. python: Python/ast.c:541: seq_for_testlist: Assertion `((n)->n_type) == 326 || ((n)->n_type) == 318 || ((n)->n_type) == 319 || ((n)->n_type) == 300' failed. Abort [epperly at tux163 numpy-1.0]$ ---------------------------------------------------------------------- >Comment By: Tom Epperly (tepperly) Date: 2006-11-03 10:58 Message: Logged In: YES user_id=94539 I think using --with-pydebug makes the assert statements live, and the default (--without-pydebug) skips the assert() statements. I think it would take a great deal of time to understand the implementation of Python well enough for me to debug this myself. Sorry, I don't think there is much I can do more than reporting it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-03 00:48 Message: Logged In: YES user_id=33168 That's weird. This is definitely a non-standard configuration, but it should work. I don't understand why it would matter if using pydebug or not. It shouldn't make a diff. It would take quite a while to setup the same config. Can you debug this further? Either find the python code that's causing the problem or the problem in the C code? My guess is the only way this could happen based on the grammar is a list inside backticks ``. But I couldn't reproduce it. ---------------------------------------------------------------------- Comment By: Tom Epperly (tepperly) Date: 2006-10-31 15:16 Message: Logged In: YES user_id=94539 If I drop the --with-pydebug from the configure line, it runs the NumPy's setup.py without error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588287&group_id=5470 From noreply at sourceforge.net Fri Nov 3 20:27:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Nov 2006 11:27:26 -0800 Subject: [ python-Bugs-1588287 ] python: Python/ast.c:541: seq_for_testlist: Assertion fails Message-ID: Bugs item #1588287, was opened at 2006-10-31 15:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588287&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tom Epperly (tepperly) Assigned to: Nobody/Anonymous (nobody) Summary: python: Python/ast.c:541: seq_for_testlist: Assertion fails Initial Comment: I 1. downloaded Python 2.5 final wget 'http://www.python.org/ftp/python/2.5/Python-2.5.tar.bz2' 2. edited Python-2.5/Objects/obmalloc.c to uncomment the #define Py_USING_MEMORY_DEBUGGER line (I plan to run valgrind on this installation of Python) 3. ./configure --without-pymalloc --with-pydebug --prefix=/somewhere/python2_5 4. make and then "make install" 5. next I downloaded and extracted numpy-1.0.tar.gz from Sourceforge: http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103 When I try to run the setup.py for numpy-1.0, I get an assertion failure. [epperly at tux163 numpy-1.0]$ python setup.py install Running from numpy source directory. python: Python/ast.c:541: seq_for_testlist: Assertion `((n)->n_type) == 326 || ((n)->n_type) == 318 || ((n)->n_type) == 319 || ((n)->n_type) == 300' failed. Abort [epperly at tux163 numpy-1.0]$ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-03 11:27 Message: Logged In: YES user_id=33168 Sorry, total brainfart. I saw the pymalloc line above and got that stuck in my mind. You are correct that assertions are only enabled with pydebug. Can you find the python code that causes the assertion to trigger. Once I have a simple test case I should be able to fix the problem fast. If my guess is correct, the code might look something like: `[]` (ie a list or generator expr inside back ticks). ---------------------------------------------------------------------- Comment By: Tom Epperly (tepperly) Date: 2006-11-03 10:58 Message: Logged In: YES user_id=94539 I think using --with-pydebug makes the assert statements live, and the default (--without-pydebug) skips the assert() statements. I think it would take a great deal of time to understand the implementation of Python well enough for me to debug this myself. Sorry, I don't think there is much I can do more than reporting it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-03 00:48 Message: Logged In: YES user_id=33168 That's weird. This is definitely a non-standard configuration, but it should work. I don't understand why it would matter if using pydebug or not. It shouldn't make a diff. It would take quite a while to setup the same config. Can you debug this further? Either find the python code that's causing the problem or the problem in the C code? My guess is the only way this could happen based on the grammar is a list inside backticks ``. But I couldn't reproduce it. ---------------------------------------------------------------------- Comment By: Tom Epperly (tepperly) Date: 2006-10-31 15:16 Message: Logged In: YES user_id=94539 If I drop the --with-pydebug from the configure line, it runs the NumPy's setup.py without error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588287&group_id=5470 From noreply at sourceforge.net Sat Nov 4 00:25:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 03 Nov 2006 15:25:18 -0800 Subject: [ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not work Message-ID: Bugs item #1579029, was opened at 2006-10-17 17:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Martin v. L?wis (loewis) Summary: --disable-sunaudiodev --disable-tk does not work Initial Comment: trying to disable sunaudiodev and tk does not really work in solaris. ./configure --prefix=/usr/local/Python-2.5 --enable- shared --disable-sunaudiodev --disable-tk building 'sunaudiodev' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/sunaudiodev.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/sunaudiodev.o /usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: sun/audioio.h: No such file or directory building '_tkinter' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -DWITH_APPINIT=1 - I/usr/openwin/include -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/_tkinter.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/_tkinter.o In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:96:23: X11/Xlib.h: No such file or directory In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:572: error: syntax error before "Window" /usr/local/include/tk.h:572: error: `Window' declared as function returning a function /usr/local/include/tk.h:575: error: syntax error before "XEvent" /usr/local/include/tk.h:584: error: syntax error before "Tk_ClassCreateProc" /usr/local/include/tk.h:592: error: syntax error before '}' token /usr/local/include/tk.h:678: error: syntax error before "Bool" is it possible to correct this or state clearly in the configure options how to disable it correctly? we also checked the Modules/Setup and both seems commented. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-04 00:25 Message: Logged In: YES user_id=21627 It doesn't build the modules, as it doesn't succeed when attempting to. Why do you want it not to attempt? ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-03 12:56 Message: Logged In: YES user_id=1597584 what do you suggest then to convince the build not to build it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-02 06:40 Message: Logged In: YES user_id=21627 Re: enable/disable: What makes you think "sunaudiodev" and "tk" are valid values for "FEATURE"? configure --help lists the valid values for FEATURE, namely universalsdk, framework, shared, profiling, toolbox-glue, ipv6, and unicode. Re: there is a compilation error. Sure, an error is reported. However, compilation should not fail because of that. Instead, compilation should complete successfully, and just end up not building these modules. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-02 00:31 Message: Logged In: YES user_id=1597584 and there is no X on the server. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:49 Message: Logged In: YES user_id=1597584 and what does that mean? Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:47 Message: Logged In: YES user_id=1597584 because there is a compilation error with both. sunaudio.h seems not to exist on our server, and tk gives other compilation errors. and i have no idea why i would need these modules on our server. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-17 17:43 Message: Logged In: YES user_id=21627 I fail to see a bug here. What makes you think --disable-sunaudiodev --disable-tk exist? ./configure --help does not claim they do. In fact, it is not possible to disable modules. Why do you want that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 From noreply at sourceforge.net Sat Nov 4 04:20:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 3 Nov 2006 19:20:03 -0800 Subject: [ python-Bugs-1576861 ] potential buffer overflow in complexobject.c Message-ID: <200611040320.kA43K3vk007826@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1576861, was opened at 2006-10-13 14:06 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576861&group_id=5470 Please note that this message 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: None Priority: 5 Private: No Submitted By: Jochen Voss (jvoss2) Assigned to: Nobody/Anonymous (nobody) Summary: potential buffer overflow in complexobject.c Initial Comment: python version 2.4.3 Hello, recently I came across the following bit of code in the source file Objects/complexobject.c: static void complex_to_buf(char *buf, int bufsz, PyComplexObject *v, int precision) { char format[32]; if (v->cval.real == 0.) { PyOS_snprintf(format, 32, "%%.%ig", precision); PyOS_ascii_formatd(buf, bufsz, format, v->cval.imag); strncat(buf, "j", bufsz); The strncat statement in the last line is potentially unsafe: the size argument of strncat determines how many characters are to be added maxmimally and not how large the buffer is in total. Also there needs to be space for an additional '\0' byte. This seems currently not exploitable, because the function 'complex_to_buf' is always called with a large enough buffer, but it should be fixed any way (for example to make sure that nobody copies this code for use in another context). I hope this helps, Jochen ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2006-11-03 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: A.M. Kuchling (akuchling) Date: 2006-10-19 14:44 Message: Logged In: YES user_id=11375 I believe this is fixed in Python 2.4.4 and Python 2.5; a static analysis tool reported the problem. Please take a look at the current trunk version at http://svn.python.org/view/python/trunk/Objects/complexobject.c?rev=50679&view=log, and see if the code seems safe now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1576861&group_id=5470 From noreply at sourceforge.net Sat Nov 4 11:01:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Nov 2006 02:01:45 -0800 Subject: [ python-Bugs-1589480 ] inspect.py imports local "tokenize.py" file Message-ID: Bugs item #1589480, was opened at 2006-11-02 12:10 Message generated for change (Settings changed) made by drfarina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589480&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Daniel Farina (drfarina) Assigned to: Nobody/Anonymous (nobody) >Summary: inspect.py imports local "tokenize.py" file Initial Comment: urllib2 may do a relative import of tokenize.py, which can cause it to function abnormally when the user has a file named "tokenizer.py" in the directory as a script that utilizes urllib2. The attached tarball has a shell script called "showme.sh" that will give standard input to afile.py, which contains two import statements and nothing else. Code in the neighboring tokenize.py will be executed, resulting in printing those lines to standard output. Expected behavior: no code in tokenize.py should be executed. Reproducible on Ubuntu 6.10 ---------------------------------------------------------------------- Comment By: Daniel Farina (drfarina) Date: 2006-11-03 10:26 Message: Logged In: YES user_id=425987 I have a fresh Ubuntu Edgy install (although my home directory is quite old and persistent). I have installed the Python 2.5 package, but am not using it in this case. You are correct, urllib2 doesn't contain the import. I still get the behavior on my machine. On my machine, the following interaction takes place: fdr at Tenacity:~/urllib2_bug$ ls afile.py show.sh tokenize.py tokenize.pyc fdr at Tenacity:~/urllib2_bug$ ./show.sh import sys import urllib2 fdr at Tenacity:~/urllib2_bug$ more show.sh #!/bin/sh cat afile.py | python afile.py fdr at Tenacity:~/urllib2_bug$ more afile.py import sys import urllib2 fdr at Tenacity:~/urllib2_bug$ As we can see from the contents of afile.py, it shouldn't be printing anything. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-03 08:20 Message: Logged In: YES user_id=849994 I can't reproduce that here with your example code, and there's also no mention of "tokenize" in urllib2.py. In any case, "import tokenize" is not a relative import, and it's the only way a standard library module can import another standard library module. That this can interfere with user-defined modules is known and must be worked around by not naming them like builtin modules. ---------------------------------------------------------------------- Comment By: Daniel Farina (drfarina) Date: 2006-11-02 12:16 Message: Logged In: YES user_id=425987 Yet another typo: the script is called "show.sh" It's the only shell script in there, so no fear. ---------------------------------------------------------------------- Comment By: Daniel Farina (drfarina) Date: 2006-11-02 12:11 Message: Logged In: YES user_id=425987 Typo in the above: "tokenizer.py" should just be "tokenize.py" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589480&group_id=5470 From noreply at sourceforge.net Sat Nov 4 11:09:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Nov 2006 02:09:23 -0800 Subject: [ python-Bugs-1589480 ] inspect.py imports local "tokenize.py" file Message-ID: Bugs item #1589480, was opened at 2006-11-02 12:10 Message generated for change (Comment added) made by drfarina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589480&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Daniel Farina (drfarina) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.py imports local "tokenize.py" file Initial Comment: urllib2 may do a relative import of tokenize.py, which can cause it to function abnormally when the user has a file named "tokenizer.py" in the directory as a script that utilizes urllib2. The attached tarball has a shell script called "showme.sh" that will give standard input to afile.py, which contains two import statements and nothing else. Code in the neighboring tokenize.py will be executed, resulting in printing those lines to standard output. Expected behavior: no code in tokenize.py should be executed. Reproducible on Ubuntu 6.10 ---------------------------------------------------------------------- >Comment By: Daniel Farina (drfarina) Date: 2006-11-04 02:09 Message: Logged In: YES user_id=425987 I have done something slightly less lazy and had the tokenize.py file throw an exception. The result was not in fact stemming from urllib2, but the inspect.py file. I have duplicated this issue on a fresh install of Edgy on a VM at work (from scratch, no home directory preservation or anything). I'm perfectly willing to accept that I should file this in Ubuntu's launchpad instead. I pray I am not a complete crackpot. Here is a new transcription of my interactions (slightly edited for brevity): [fdr at Tenacity ~/inspect_bug]$ more * :::::::::::::: afile.py :::::::::::::: import inspect #some random text. #more text. #maybe even some more. :::::::::::::: show.sh :::::::::::::: #!/bin/sh cat afile.py | python afile.py :::::::::::::: tokenize.py :::::::::::::: import sys for line in sys.stdin: print line raise Exception, 'Shouldn\'t be here' [fdr at Tenacity ~/inspect_bug]$ ./show.sh import inspect #some random text. #more text. #maybe even some more. Traceback (most recent call last): File "afile.py", line 1, in ? import inspect File "/usr/lib/python2.4/inspect.py", line 31, in ? import sys, os, types, string, re, dis, imp, tokenize, linecache File "/home/fdr/inspect_bug/tokenize.py", line 6, in ? raise Exception, 'Shouldn\'t be here' Exception: Shouldn't be here [fdr at Tenacity ~/inspect_bug]$ ---------------------------------------------------------------------- Comment By: Daniel Farina (drfarina) Date: 2006-11-03 10:26 Message: Logged In: YES user_id=425987 I have a fresh Ubuntu Edgy install (although my home directory is quite old and persistent). I have installed the Python 2.5 package, but am not using it in this case. You are correct, urllib2 doesn't contain the import. I still get the behavior on my machine. On my machine, the following interaction takes place: fdr at Tenacity:~/urllib2_bug$ ls afile.py show.sh tokenize.py tokenize.pyc fdr at Tenacity:~/urllib2_bug$ ./show.sh import sys import urllib2 fdr at Tenacity:~/urllib2_bug$ more show.sh #!/bin/sh cat afile.py | python afile.py fdr at Tenacity:~/urllib2_bug$ more afile.py import sys import urllib2 fdr at Tenacity:~/urllib2_bug$ As we can see from the contents of afile.py, it shouldn't be printing anything. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-03 08:20 Message: Logged In: YES user_id=849994 I can't reproduce that here with your example code, and there's also no mention of "tokenize" in urllib2.py. In any case, "import tokenize" is not a relative import, and it's the only way a standard library module can import another standard library module. That this can interfere with user-defined modules is known and must be worked around by not naming them like builtin modules. ---------------------------------------------------------------------- Comment By: Daniel Farina (drfarina) Date: 2006-11-02 12:16 Message: Logged In: YES user_id=425987 Yet another typo: the script is called "show.sh" It's the only shell script in there, so no fear. ---------------------------------------------------------------------- Comment By: Daniel Farina (drfarina) Date: 2006-11-02 12:11 Message: Logged In: YES user_id=425987 Typo in the above: "tokenizer.py" should just be "tokenize.py" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589480&group_id=5470 From noreply at sourceforge.net Sat Nov 4 16:27:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Nov 2006 07:27:55 -0800 Subject: [ python-Bugs-1589480 ] inspect.py imports local "tokenize.py" file Message-ID: Bugs item #1589480, was opened at 2006-11-02 21:10 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589480&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Daniel Farina (drfarina) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.py imports local "tokenize.py" file Initial Comment: urllib2 may do a relative import of tokenize.py, which can cause it to function abnormally when the user has a file named "tokenizer.py" in the directory as a script that utilizes urllib2. The attached tarball has a shell script called "showme.sh" that will give standard input to afile.py, which contains two import statements and nothing else. Code in the neighboring tokenize.py will be executed, resulting in printing those lines to standard output. Expected behavior: no code in tokenize.py should be executed. Reproducible on Ubuntu 6.10 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-04 16:27 Message: Logged In: YES user_id=21627 As gbrandl explains, it is an error to name your own modules with the names of the modules of the standard library. As you have a module named tokenize, and as tokenize is also a module of the standard library, the bug is in your code. Closing this report as invalid. ---------------------------------------------------------------------- Comment By: Daniel Farina (drfarina) Date: 2006-11-04 11:09 Message: Logged In: YES user_id=425987 I have done something slightly less lazy and had the tokenize.py file throw an exception. The result was not in fact stemming from urllib2, but the inspect.py file. I have duplicated this issue on a fresh install of Edgy on a VM at work (from scratch, no home directory preservation or anything). I'm perfectly willing to accept that I should file this in Ubuntu's launchpad instead. I pray I am not a complete crackpot. Here is a new transcription of my interactions (slightly edited for brevity): [fdr at Tenacity ~/inspect_bug]$ more * :::::::::::::: afile.py :::::::::::::: import inspect #some random text. #more text. #maybe even some more. :::::::::::::: show.sh :::::::::::::: #!/bin/sh cat afile.py | python afile.py :::::::::::::: tokenize.py :::::::::::::: import sys for line in sys.stdin: print line raise Exception, 'Shouldn\'t be here' [fdr at Tenacity ~/inspect_bug]$ ./show.sh import inspect #some random text. #more text. #maybe even some more. Traceback (most recent call last): File "afile.py", line 1, in ? import inspect File "/usr/lib/python2.4/inspect.py", line 31, in ? import sys, os, types, string, re, dis, imp, tokenize, linecache File "/home/fdr/inspect_bug/tokenize.py", line 6, in ? raise Exception, 'Shouldn\'t be here' Exception: Shouldn't be here [fdr at Tenacity ~/inspect_bug]$ ---------------------------------------------------------------------- Comment By: Daniel Farina (drfarina) Date: 2006-11-03 19:26 Message: Logged In: YES user_id=425987 I have a fresh Ubuntu Edgy install (although my home directory is quite old and persistent). I have installed the Python 2.5 package, but am not using it in this case. You are correct, urllib2 doesn't contain the import. I still get the behavior on my machine. On my machine, the following interaction takes place: fdr at Tenacity:~/urllib2_bug$ ls afile.py show.sh tokenize.py tokenize.pyc fdr at Tenacity:~/urllib2_bug$ ./show.sh import sys import urllib2 fdr at Tenacity:~/urllib2_bug$ more show.sh #!/bin/sh cat afile.py | python afile.py fdr at Tenacity:~/urllib2_bug$ more afile.py import sys import urllib2 fdr at Tenacity:~/urllib2_bug$ As we can see from the contents of afile.py, it shouldn't be printing anything. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-03 17:20 Message: Logged In: YES user_id=849994 I can't reproduce that here with your example code, and there's also no mention of "tokenize" in urllib2.py. In any case, "import tokenize" is not a relative import, and it's the only way a standard library module can import another standard library module. That this can interfere with user-defined modules is known and must be worked around by not naming them like builtin modules. ---------------------------------------------------------------------- Comment By: Daniel Farina (drfarina) Date: 2006-11-02 21:16 Message: Logged In: YES user_id=425987 Yet another typo: the script is called "show.sh" It's the only shell script in there, so no fear. ---------------------------------------------------------------------- Comment By: Daniel Farina (drfarina) Date: 2006-11-02 21:11 Message: Logged In: YES user_id=425987 Typo in the above: "tokenizer.py" should just be "tokenize.py" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589480&group_id=5470 From noreply at sourceforge.net Sat Nov 4 16:29:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Nov 2006 07:29:05 -0800 Subject: [ python-Bugs-1589074 ] Unneeded constants left during optimization Message-ID: Bugs item #1589074, was opened at 2006-11-02 06:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589074&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel (kamek) Assigned to: Nobody/Anonymous (nobody) Summary: Unneeded constants left during optimization Initial Comment: At some point, when generating the bytecode, the parser/compiler pre-calculates operations on constants. However, the old values, which are often not needed anymore in the constants, are left there as garbage. To keep this description from being lengthy, I'm attaching a text file with several simple demonstrations that serve as testcases. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-04 16:29 Message: Logged In: YES user_id=21627 Would you like to work on a patch to fix this problem? ---------------------------------------------------------------------- Comment By: Daniel (kamek) Date: 2006-11-02 06:58 Message: Logged In: YES user_id=539453 Sorry, I rushed and missed the File Description field. Should be "Interactive interpreter testcases". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589074&group_id=5470 From noreply at sourceforge.net Sat Nov 4 20:33:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Nov 2006 11:33:53 -0800 Subject: [ python-Bugs-1588287 ] python: Python/ast.c:541: seq_for_testlist: Assertion fails Message-ID: Bugs item #1588287, was opened at 2006-10-31 15:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588287&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Tom Epperly (tepperly) >Assigned to: Neal Norwitz (nnorwitz) Summary: python: Python/ast.c:541: seq_for_testlist: Assertion fails Initial Comment: I 1. downloaded Python 2.5 final wget 'http://www.python.org/ftp/python/2.5/Python-2.5.tar.bz2' 2. edited Python-2.5/Objects/obmalloc.c to uncomment the #define Py_USING_MEMORY_DEBUGGER line (I plan to run valgrind on this installation of Python) 3. ./configure --without-pymalloc --with-pydebug --prefix=/somewhere/python2_5 4. make and then "make install" 5. next I downloaded and extracted numpy-1.0.tar.gz from Sourceforge: http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103 When I try to run the setup.py for numpy-1.0, I get an assertion failure. [epperly at tux163 numpy-1.0]$ python setup.py install Running from numpy source directory. python: Python/ast.c:541: seq_for_testlist: Assertion `((n)->n_type) == 326 || ((n)->n_type) == 318 || ((n)->n_type) == 319 || ((n)->n_type) == 300' failed. Abort [epperly at tux163 numpy-1.0]$ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-04 11:33 Message: Logged In: YES user_id=33168 Thanks for the report. My guess was close, the problem was: `1,2`. Committed revision 52621. (2.6) Committed revision 52622. (2.5.1) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-03 11:27 Message: Logged In: YES user_id=33168 Sorry, total brainfart. I saw the pymalloc line above and got that stuck in my mind. You are correct that assertions are only enabled with pydebug. Can you find the python code that causes the assertion to trigger. Once I have a simple test case I should be able to fix the problem fast. If my guess is correct, the code might look something like: `[]` (ie a list or generator expr inside back ticks). ---------------------------------------------------------------------- Comment By: Tom Epperly (tepperly) Date: 2006-11-03 10:58 Message: Logged In: YES user_id=94539 I think using --with-pydebug makes the assert statements live, and the default (--without-pydebug) skips the assert() statements. I think it would take a great deal of time to understand the implementation of Python well enough for me to debug this myself. Sorry, I don't think there is much I can do more than reporting it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-03 00:48 Message: Logged In: YES user_id=33168 That's weird. This is definitely a non-standard configuration, but it should work. I don't understand why it would matter if using pydebug or not. It shouldn't make a diff. It would take quite a while to setup the same config. Can you debug this further? Either find the python code that's causing the problem or the problem in the C code? My guess is the only way this could happen based on the grammar is a list inside backticks ``. But I couldn't reproduce it. ---------------------------------------------------------------------- Comment By: Tom Epperly (tepperly) Date: 2006-10-31 15:16 Message: Logged In: YES user_id=94539 If I drop the --with-pydebug from the configure line, it runs the NumPy's setup.py without error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588287&group_id=5470 From noreply at sourceforge.net Sat Nov 4 20:36:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Nov 2006 11:36:49 -0800 Subject: [ python-Bugs-1588287 ] python: Python/ast.c:541: seq_for_testlist: Assertion fails Message-ID: Bugs item #1588287, was opened at 2006-10-31 15:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588287&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Tom Epperly (tepperly) Assigned to: Neal Norwitz (nnorwitz) Summary: python: Python/ast.c:541: seq_for_testlist: Assertion fails Initial Comment: I 1. downloaded Python 2.5 final wget 'http://www.python.org/ftp/python/2.5/Python-2.5.tar.bz2' 2. edited Python-2.5/Objects/obmalloc.c to uncomment the #define Py_USING_MEMORY_DEBUGGER line (I plan to run valgrind on this installation of Python) 3. ./configure --without-pymalloc --with-pydebug --prefix=/somewhere/python2_5 4. make and then "make install" 5. next I downloaded and extracted numpy-1.0.tar.gz from Sourceforge: http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=175103 When I try to run the setup.py for numpy-1.0, I get an assertion failure. [epperly at tux163 numpy-1.0]$ python setup.py install Running from numpy source directory. python: Python/ast.c:541: seq_for_testlist: Assertion `((n)->n_type) == 326 || ((n)->n_type) == 318 || ((n)->n_type) == 319 || ((n)->n_type) == 300' failed. Abort [epperly at tux163 numpy-1.0]$ ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-04 11:36 Message: Logged In: YES user_id=33168 Note: If you change `1,2` to `(1,2)` the assertion won't trigger. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-04 11:33 Message: Logged In: YES user_id=33168 Thanks for the report. My guess was close, the problem was: `1,2`. Committed revision 52621. (2.6) Committed revision 52622. (2.5.1) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-03 11:27 Message: Logged In: YES user_id=33168 Sorry, total brainfart. I saw the pymalloc line above and got that stuck in my mind. You are correct that assertions are only enabled with pydebug. Can you find the python code that causes the assertion to trigger. Once I have a simple test case I should be able to fix the problem fast. If my guess is correct, the code might look something like: `[]` (ie a list or generator expr inside back ticks). ---------------------------------------------------------------------- Comment By: Tom Epperly (tepperly) Date: 2006-11-03 10:58 Message: Logged In: YES user_id=94539 I think using --with-pydebug makes the assert statements live, and the default (--without-pydebug) skips the assert() statements. I think it would take a great deal of time to understand the implementation of Python well enough for me to debug this myself. Sorry, I don't think there is much I can do more than reporting it. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-03 00:48 Message: Logged In: YES user_id=33168 That's weird. This is definitely a non-standard configuration, but it should work. I don't understand why it would matter if using pydebug or not. It shouldn't make a diff. It would take quite a while to setup the same config. Can you debug this further? Either find the python code that's causing the problem or the problem in the C code? My guess is the only way this could happen based on the grammar is a list inside backticks ``. But I couldn't reproduce it. ---------------------------------------------------------------------- Comment By: Tom Epperly (tepperly) Date: 2006-10-31 15:16 Message: Logged In: YES user_id=94539 If I drop the --with-pydebug from the configure line, it runs the NumPy's setup.py without error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588287&group_id=5470 From noreply at sourceforge.net Sat Nov 4 20:40:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Nov 2006 11:40:19 -0800 Subject: [ python-Bugs-1590036 ] __getattr__ = getattr crash Message-ID: Bugs item #1590036, was opened at 2006-11-03 08:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590036&group_id=5470 Please note that this message 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: 6 Private: No Submitted By: Brian Harring (ferringb) >Assigned to: Armin Rigo (arigo) Summary: __getattr__ = getattr crash Initial Comment: class c(object):__getattr__ = getattr c().spam Now granted... it's retarded to attempt this. But out of curiousity, I decided to be the retard, and noticed the interpreter crashes instead of triggering a RuntimeError for recursion. As far as I know, getattr is instrumented with Py_EnterRecursiveCall and Py_LEaveRecursiveCall... so a bit curious as to how it's occuring. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-04 11:40 Message: Logged In: YES user_id=33168 The attached patch fixes this problem. However, I'm concerned there are more places like this. I hope Armin has some ideas if more things are needed to fix this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590036&group_id=5470 From noreply at sourceforge.net Sat Nov 4 20:51:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Nov 2006 11:51:37 -0800 Subject: [ python-Bugs-1590592 ] where is zlib??? Message-ID: Bugs item #1590592, was opened at 2006-11-04 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=1590592&group_id=5470 Please note that this 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 Private: No Submitted By: AKap (aleksey_kap) Assigned to: Nobody/Anonymous (nobody) Summary: where is zlib??? Initial Comment: Python2.5 for win32 msi-installer - where are zlib.dll and zlib.pyd ??? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590592&group_id=5470 From noreply at sourceforge.net Sat Nov 4 21:40:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Nov 2006 12:40:01 -0800 Subject: [ python-Bugs-1589480 ] inspect.py imports local "tokenize.py" file Message-ID: Bugs item #1589480, was opened at 2006-11-02 12:10 Message generated for change (Comment added) made by drfarina You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589480&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Daniel Farina (drfarina) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.py imports local "tokenize.py" file Initial Comment: urllib2 may do a relative import of tokenize.py, which can cause it to function abnormally when the user has a file named "tokenizer.py" in the directory as a script that utilizes urllib2. The attached tarball has a shell script called "showme.sh" that will give standard input to afile.py, which contains two import statements and nothing else. Code in the neighboring tokenize.py will be executed, resulting in printing those lines to standard output. Expected behavior: no code in tokenize.py should be executed. Reproducible on Ubuntu 6.10 ---------------------------------------------------------------------- >Comment By: Daniel Farina (drfarina) Date: 2006-11-04 12:40 Message: Logged In: YES user_id=425987 Oops. Sorry about that... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-04 07:27 Message: Logged In: YES user_id=21627 As gbrandl explains, it is an error to name your own modules with the names of the modules of the standard library. As you have a module named tokenize, and as tokenize is also a module of the standard library, the bug is in your code. Closing this report as invalid. ---------------------------------------------------------------------- Comment By: Daniel Farina (drfarina) Date: 2006-11-04 02:09 Message: Logged In: YES user_id=425987 I have done something slightly less lazy and had the tokenize.py file throw an exception. The result was not in fact stemming from urllib2, but the inspect.py file. I have duplicated this issue on a fresh install of Edgy on a VM at work (from scratch, no home directory preservation or anything). I'm perfectly willing to accept that I should file this in Ubuntu's launchpad instead. I pray I am not a complete crackpot. Here is a new transcription of my interactions (slightly edited for brevity): [fdr at Tenacity ~/inspect_bug]$ more * :::::::::::::: afile.py :::::::::::::: import inspect #some random text. #more text. #maybe even some more. :::::::::::::: show.sh :::::::::::::: #!/bin/sh cat afile.py | python afile.py :::::::::::::: tokenize.py :::::::::::::: import sys for line in sys.stdin: print line raise Exception, 'Shouldn\'t be here' [fdr at Tenacity ~/inspect_bug]$ ./show.sh import inspect #some random text. #more text. #maybe even some more. Traceback (most recent call last): File "afile.py", line 1, in ? import inspect File "/usr/lib/python2.4/inspect.py", line 31, in ? import sys, os, types, string, re, dis, imp, tokenize, linecache File "/home/fdr/inspect_bug/tokenize.py", line 6, in ? raise Exception, 'Shouldn\'t be here' Exception: Shouldn't be here [fdr at Tenacity ~/inspect_bug]$ ---------------------------------------------------------------------- Comment By: Daniel Farina (drfarina) Date: 2006-11-03 10:26 Message: Logged In: YES user_id=425987 I have a fresh Ubuntu Edgy install (although my home directory is quite old and persistent). I have installed the Python 2.5 package, but am not using it in this case. You are correct, urllib2 doesn't contain the import. I still get the behavior on my machine. On my machine, the following interaction takes place: fdr at Tenacity:~/urllib2_bug$ ls afile.py show.sh tokenize.py tokenize.pyc fdr at Tenacity:~/urllib2_bug$ ./show.sh import sys import urllib2 fdr at Tenacity:~/urllib2_bug$ more show.sh #!/bin/sh cat afile.py | python afile.py fdr at Tenacity:~/urllib2_bug$ more afile.py import sys import urllib2 fdr at Tenacity:~/urllib2_bug$ As we can see from the contents of afile.py, it shouldn't be printing anything. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-03 08:20 Message: Logged In: YES user_id=849994 I can't reproduce that here with your example code, and there's also no mention of "tokenize" in urllib2.py. In any case, "import tokenize" is not a relative import, and it's the only way a standard library module can import another standard library module. That this can interfere with user-defined modules is known and must be worked around by not naming them like builtin modules. ---------------------------------------------------------------------- Comment By: Daniel Farina (drfarina) Date: 2006-11-02 12:16 Message: Logged In: YES user_id=425987 Yet another typo: the script is called "show.sh" It's the only shell script in there, so no fear. ---------------------------------------------------------------------- Comment By: Daniel Farina (drfarina) Date: 2006-11-02 12:11 Message: Logged In: YES user_id=425987 Typo in the above: "tokenizer.py" should just be "tokenize.py" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1589480&group_id=5470 From noreply at sourceforge.net Sun Nov 5 04:57:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Nov 2006 19:57:59 -0800 Subject: [ python-Bugs-1590036 ] __getattr__ = getattr crash Message-ID: Bugs item #1590036, was opened at 2006-11-03 10:44 Message generated for change (Comment added) made by ferringb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590036&group_id=5470 Please note that this message 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: 6 Private: No Submitted By: Brian Harring (ferringb) Assigned to: Armin Rigo (arigo) Summary: __getattr__ = getattr crash Initial Comment: class c(object):__getattr__ = getattr c().spam Now granted... it's retarded to attempt this. But out of curiousity, I decided to be the retard, and noticed the interpreter crashes instead of triggering a RuntimeError for recursion. As far as I know, getattr is instrumented with Py_EnterRecursiveCall and Py_LEaveRecursiveCall... so a bit curious as to how it's occuring. ---------------------------------------------------------------------- >Comment By: Brian Harring (ferringb) Date: 2006-11-04 21:57 Message: Logged In: YES user_id=874085 can do the same trick with hasattr also (same type of fix)... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-04 13:40 Message: Logged In: YES user_id=33168 The attached patch fixes this problem. However, I'm concerned there are more places like this. I hope Armin has some ideas if more things are needed to fix this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590036&group_id=5470 From noreply at sourceforge.net Sun Nov 5 05:06:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 04 Nov 2006 20:06:31 -0800 Subject: [ python-Bugs-1574217 ] isinstance swallows exceptions Message-ID: Bugs item #1574217, was opened at 2006-10-09 21:55 Message generated for change (Comment added) made by ferringb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574217&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Brian Harring (ferringb) Assigned to: Nobody/Anonymous (nobody) Summary: isinstance swallows exceptions Initial Comment: Attached is a simple example; yes, a bit contrived, but it's exactly what bit me in the ass for a week or two :) nestled within abstract.c's recursive_isinstance, is this lil nugget- icls = PyObject_GetAttr(inst, __class__); if (icls == NULL) { PyErr_Clear(); retval = 0; } else { No surrouding comments to indicate *why* it's swallowing exceptions, but best explanation I've heard was that it was attempting to swallow just AttributeError... which would make sense. So the question is, whats the purpose of it swallowing exceptions there? Bad form of AttributeError catching, or some unstated reason? ---------------------------------------------------------------------- >Comment By: Brian Harring (ferringb) Date: 2006-11-04 22:06 Message: Logged In: YES user_id=874085 quicky patch for this; basically, wipe the exception only if it's AttributeError, else let it bubble it's way up. ---------------------------------------------------------------------- Comment By: Brian Harring (ferringb) Date: 2006-10-09 21:56 Message: Logged In: YES user_id=874085 addition note; this is both 2.5 and 2.4, probably stretches bit further back also. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574217&group_id=5470 From noreply at sourceforge.net Sun Nov 5 10:21:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 01:21:05 -0800 Subject: [ python-Bugs-1590744 ] mail message parsing glitch Message-ID: Bugs item #1590744, was opened at 2006-11-05 04: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=1590744&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Mike (mcspang) Assigned to: Nobody/Anonymous (nobody) Summary: mail message parsing glitch Initial Comment: There's something wrong with the handling of line continuation in headers. In the attached mbox the 'Message-id' header is read and stored with a leading space. So message_id = ' <9B09D75DF5B3494BA06E6FE478CE9CC10526CFAF at mgtserver3.ontario.int.ec.gc.ca>' when it's first read. If you write this message out to a new mbox, it is written with the leading space and without the newline. THEN, if you read it in AGAIN, the parser ignores the leading space. One of these steps is buggy, I'm not sure which. It seems to me that the value returned by msg['Message_id'] should not change when the file is written then re-read. In the initial read and final reads above the value differs by a space. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590744&group_id=5470 From noreply at sourceforge.net Sun Nov 5 10:30:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 01:30:48 -0800 Subject: [ python-Bugs-1590036 ] __getattr__ = getattr crash Message-ID: Bugs item #1590036, was opened at 2006-11-03 16:44 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590036&group_id=5470 Please note that this message 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: Duplicate Priority: 6 Private: No Submitted By: Brian Harring (ferringb) Assigned to: Armin Rigo (arigo) Summary: __getattr__ = getattr crash Initial Comment: class c(object):__getattr__ = getattr c().spam Now granted... it's retarded to attempt this. But out of curiousity, I decided to be the retard, and noticed the interpreter crashes instead of triggering a RuntimeError for recursion. As far as I know, getattr is instrumented with Py_EnterRecursiveCall and Py_LEaveRecursiveCall... so a bit curious as to how it's occuring. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-11-05 09:30 Message: Logged In: YES user_id=4771 This is a particular case of bug #1202533. With Brett we arrived at a patch in #1202533 which should solve a family of similar problems. Can you check that it also solves the __getattr__=getattr attack? If so, we should check in Brett's patch. ---------------------------------------------------------------------- Comment By: Brian Harring (ferringb) Date: 2006-11-05 03:57 Message: Logged In: YES user_id=874085 can do the same trick with hasattr also (same type of fix)... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-04 19:40 Message: Logged In: YES user_id=33168 The attached patch fixes this problem. However, I'm concerned there are more places like this. I hope Armin has some ideas if more things are needed to fix this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590036&group_id=5470 From noreply at sourceforge.net Sun Nov 5 14:13:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 05:13:38 -0800 Subject: [ python-Bugs-1590804 ] python: Python/ast.c:541: seq_for_testlist: Assertion Message-ID: Bugs item #1590804, was opened at 2006-11-05 08: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=1590804&group_id=5470 Please note that this message 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: AST Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) Summary: python: Python/ast.c:541: seq_for_testlist: Assertion Initial Comment: When I build Python for debug using --with-pydebug on linux platforms (RHEL3 or FC6) I get the following assertion error when I try to install numpy-1.0: [jmiller at localhost numpy-1.0]$ python setup.py install Running from numpy source directory. python: Python/ast.c:541: seq_for_testlist: Assertion `((n)->n_type) == 326 || ((n)->n_type) == 318 || ((n)->n_type) == 319 || ((n)->n_type) == 300' failed. Abort ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590804&group_id=5470 From noreply at sourceforge.net Sun Nov 5 17:06:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 08:06:24 -0800 Subject: [ python-Bugs-1590864 ] subprocess deadlock Message-ID: Bugs item #1590864, was opened at 2006-11-05 11:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590864&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Michael Tsai (michaeltsai) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess deadlock Initial Comment: When I use subprocess.py from a child thread, sometimes it deadlocks. I determined that the new process is blocked during an import: #0 0x90024427 in semaphore_wait_signal_trap () #1 0x90028414 in pthread_cond_wait () #2 0x004c77bf in PyThread_acquire_lock (lock=0x3189a0, waitflag=1) at Python/thread_pthread.h:452 #3 0x004ae2a6 in lock_import () at Python/import.c:266 #4 0x004b24be in PyImport_ImportModuleLevel (name=0xaad74 "errno", globals=0xbaed0, locals=0x502aa0, fromlist=0xc1378, level=-1) at Python/import.c:2054 #5 0x0048d2e2 in builtin___import__ (self=0x0, args=0x53724c90, kwds=0x0) at Python/bltinmodule.c:47 #6 0x0040decb in PyObject_Call (func=0xa94b8, arg=0x53724c90, kw=0x0) at Objects/abstract.c:1860 and that the code in question is in os.py: def _execvpe(file, args, env=None): from errno import ENOENT, ENOTDIR I think the problem is that since exec (the C function) hasn't yet been called in the new process, it's inherited from the fork a lock that's already held. The main process will eventually release its copy of the lock, but this will not unlock it in the new process, so it deadlocks. If I change os.py so that it imports the constants outside of _execvpe, the new process no longer blocks in this way. This is on Mac OS X 10.4.8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590864&group_id=5470 From noreply at sourceforge.net Sun Nov 5 17:54:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 08:54:06 -0800 Subject: [ python-Bugs-1590891 ] random.randrange don't return correct value for big number Message-ID: Bugs item #1590891, was opened at 2006-11-06 01:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590891&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: MATSUI Tetsushi (mft) Assigned to: Nobody/Anonymous (nobody) Summary: random.randrange don't return correct value for big number Initial Comment: Python 2.4.3 (#1, Oct 3 2006, 00:36:06) [GCC 4.1.1 (Gentoo 4.1.1-r1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import random >>> random.randrange(1000000000000, -100000000000000000000, -200) 267471051174796896L Obviously, the result is not in the specified range; 1000000000000 < 267471051174796896, -100000000000000000000 < 267471051174796896 and (267471051174796896 - 1000000000000) % (-200) != 0. I'm using 2.3.5 and 2.4.3, and their behaviors are identical. I haven't checked about 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590891&group_id=5470 From noreply at sourceforge.net Sun Nov 5 21:10:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 12:10:48 -0800 Subject: [ python-Bugs-1590891 ] random.randrange don't return correct value for big number Message-ID: Bugs item #1590891, was opened at 2006-11-05 11:54 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590891&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: MATSUI Tetsushi (mft) >Assigned to: Raymond Hettinger (rhettinger) Summary: random.randrange don't return correct value for big number Initial Comment: Python 2.4.3 (#1, Oct 3 2006, 00:36:06) [GCC 4.1.1 (Gentoo 4.1.1-r1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import random >>> random.randrange(1000000000000, -100000000000000000000, -200) 267471051174796896L Obviously, the result is not in the specified range; 1000000000000 < 267471051174796896, -100000000000000000000 < 267471051174796896 and (267471051174796896 - 1000000000000) % (-200) != 0. I'm using 2.3.5 and 2.4.3, and their behaviors are identical. I haven't checked about 2.5. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590891&group_id=5470 From noreply at sourceforge.net Sun Nov 5 21:39:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 12:39:50 -0800 Subject: [ python-Feature Requests-1589074 ] Unneeded constants left during optimization Message-ID: Feature Requests item #1589074, was opened at 2006-11-02 00:55 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1589074&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel (kamek) Assigned to: Nobody/Anonymous (nobody) Summary: Unneeded constants left during optimization Initial Comment: At some point, when generating the bytecode, the parser/compiler pre-calculates operations on constants. However, the old values, which are often not needed anymore in the constants, are left there as garbage. To keep this description from being lengthy, I'm attaching a text file with several simple demonstrations that serve as testcases. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-11-05 15:39 Message: Logged In: YES user_id=80475 I looked at this when constant folding was first introduced and it did not seem worth doing because 1) it would be somewhat complicated to implement (counting each time a constant is used and renumbering all constant references once a deletion occurs), 2) it would be hard to maintain, 3) it would slow-down compilation, and 4) the potential benefit is microscopic (saving a few bytes but not improving execution speed). Here's an example of the difficulty: >>> def f(): x = 3 y = 3 + 4 return x + y >>> f.func_code.co_consts (None, 3, 4, 7) The constant folding for 3+4 introduces the 7 but cannot easily know that the 3 is used elsewhere while the 4 is not. Am reclassifying this as a feature request for a trivial space optimization (there is no bug, the peepholer is functioning as designed). This suggestion could be implemented but (IMO) is not worth it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-04 10:29 Message: Logged In: YES user_id=21627 Would you like to work on a patch to fix this problem? ---------------------------------------------------------------------- Comment By: Daniel (kamek) Date: 2006-11-02 00:58 Message: Logged In: YES user_id=539453 Sorry, I rushed and missed the File Description field. Should be "Interactive interpreter testcases". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1589074&group_id=5470 From noreply at sourceforge.net Sun Nov 5 22:12:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 13:12:42 -0800 Subject: [ python-Feature Requests-1589074 ] Unneeded constants left during optimization Message-ID: Feature Requests item #1589074, was opened at 2006-11-02 01:55 Message generated for change (Comment added) made by kamek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1589074&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Daniel (kamek) Assigned to: Nobody/Anonymous (nobody) Summary: Unneeded constants left during optimization Initial Comment: At some point, when generating the bytecode, the parser/compiler pre-calculates operations on constants. However, the old values, which are often not needed anymore in the constants, are left there as garbage. To keep this description from being lengthy, I'm attaching a text file with several simple demonstrations that serve as testcases. ---------------------------------------------------------------------- >Comment By: Daniel (kamek) Date: 2006-11-05 17:12 Message: Logged In: YES user_id=539453 loewis: Sorry, I'm afraid I don't have enough knowledge on Python's internals to work on it. rhettinger: Well, that's bad, but I did expect that; I agree the actual benefits would be minimal, especially considering how relatively rare this optimization occurs and how those constants are often quite light on memory usage. But what about intermediate constants (which we are sure that aren't used elsewhere, like in 3 + 4 + 10)? Would it be easier to get rid of them (or maybe reuse previously defined constants when available)? All in all, sorry for being too nitpicky. I know this isn't any crucial issue :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-11-05 16:39 Message: Logged In: YES user_id=80475 I looked at this when constant folding was first introduced and it did not seem worth doing because 1) it would be somewhat complicated to implement (counting each time a constant is used and renumbering all constant references once a deletion occurs), 2) it would be hard to maintain, 3) it would slow-down compilation, and 4) the potential benefit is microscopic (saving a few bytes but not improving execution speed). Here's an example of the difficulty: >>> def f(): x = 3 y = 3 + 4 return x + y >>> f.func_code.co_consts (None, 3, 4, 7) The constant folding for 3+4 introduces the 7 but cannot easily know that the 3 is used elsewhere while the 4 is not. Am reclassifying this as a feature request for a trivial space optimization (there is no bug, the peepholer is functioning as designed). This suggestion could be implemented but (IMO) is not worth it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-04 11:29 Message: Logged In: YES user_id=21627 Would you like to work on a patch to fix this problem? ---------------------------------------------------------------------- Comment By: Daniel (kamek) Date: 2006-11-02 01:58 Message: Logged In: YES user_id=539453 Sorry, I rushed and missed the File Description field. Should be "Interactive interpreter testcases". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1589074&group_id=5470 From noreply at sourceforge.net Sun Nov 5 23:07:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 14:07:45 -0800 Subject: [ python-Feature Requests-1589074 ] Unneeded constants left during optimization Message-ID: Feature Requests item #1589074, was opened at 2006-11-02 06:55 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1589074&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Daniel (kamek) Assigned to: Nobody/Anonymous (nobody) Summary: Unneeded constants left during optimization Initial Comment: At some point, when generating the bytecode, the parser/compiler pre-calculates operations on constants. However, the old values, which are often not needed anymore in the constants, are left there as garbage. To keep this description from being lengthy, I'm attaching a text file with several simple demonstrations that serve as testcases. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-05 23:07 Message: Logged In: YES user_id=21627 kamek: with the current peephole pass, it wouldn't be easy to eliminate intermediate constants. The peephole operates on individual instructions, introducing a new constant each time. That code would have to track what constants were originally there and which ones are new, and then would also have to take into account that the constant numbering must not change (so you can always only eliminate the last constant, unless you add an entire new pass that renumbers all opcodes that refer to constants). Closing this as "won't fix", then, as nobody seems to be willing to work on it. If this is ever attempted, I think the constant folding should happen on the AST level, rather than on the bytecode level. ---------------------------------------------------------------------- Comment By: Daniel (kamek) Date: 2006-11-05 22:12 Message: Logged In: YES user_id=539453 loewis: Sorry, I'm afraid I don't have enough knowledge on Python's internals to work on it. rhettinger: Well, that's bad, but I did expect that; I agree the actual benefits would be minimal, especially considering how relatively rare this optimization occurs and how those constants are often quite light on memory usage. But what about intermediate constants (which we are sure that aren't used elsewhere, like in 3 + 4 + 10)? Would it be easier to get rid of them (or maybe reuse previously defined constants when available)? All in all, sorry for being too nitpicky. I know this isn't any crucial issue :) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-11-05 21:39 Message: Logged In: YES user_id=80475 I looked at this when constant folding was first introduced and it did not seem worth doing because 1) it would be somewhat complicated to implement (counting each time a constant is used and renumbering all constant references once a deletion occurs), 2) it would be hard to maintain, 3) it would slow-down compilation, and 4) the potential benefit is microscopic (saving a few bytes but not improving execution speed). Here's an example of the difficulty: >>> def f(): x = 3 y = 3 + 4 return x + y >>> f.func_code.co_consts (None, 3, 4, 7) The constant folding for 3+4 introduces the 7 but cannot easily know that the 3 is used elsewhere while the 4 is not. Am reclassifying this as a feature request for a trivial space optimization (there is no bug, the peepholer is functioning as designed). This suggestion could be implemented but (IMO) is not worth it. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-04 16:29 Message: Logged In: YES user_id=21627 Would you like to work on a patch to fix this problem? ---------------------------------------------------------------------- Comment By: Daniel (kamek) Date: 2006-11-02 06:58 Message: Logged In: YES user_id=539453 Sorry, I rushed and missed the File Description field. Should be "Interactive interpreter testcases". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1589074&group_id=5470 From noreply at sourceforge.net Sun Nov 5 23:23:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 14:23:13 -0800 Subject: [ python-Bugs-1590804 ] python: Python/ast.c:541: seq_for_testlist: Assertion Message-ID: Bugs item #1590804, was opened at 2006-11-05 14:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590804&group_id=5470 Please note that this message 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: AST Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) Summary: python: Python/ast.c:541: seq_for_testlist: Assertion Initial Comment: When I build Python for debug using --with-pydebug on linux platforms (RHEL3 or FC6) I get the following assertion error when I try to install numpy-1.0: [jmiller at localhost numpy-1.0]$ python setup.py install Running from numpy source directory. python: Python/ast.c:541: seq_for_testlist: Assertion `((n)->n_type) == 326 || ((n)->n_type) == 318 || ((n)->n_type) == 319 || ((n)->n_type) == 300' failed. Abort ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-05 23:23 Message: Logged In: YES user_id=21627 Thanks for the report. Attached is a simplified test case, and a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590804&group_id=5470 From noreply at sourceforge.net Sun Nov 5 23:27:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 14:27:29 -0800 Subject: [ python-Bugs-1591035 ] update urlparse to RFC 3986 Message-ID: Bugs item #1591035, was opened at 2006-11-05 15: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=1591035&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) Summary: update urlparse to RFC 3986 Initial Comment: urlparse implements RFC 1808. That is strongly out of date. The most recent is RFC 3986. Here is a text from 4Suite # Reasons to avoid using urllib.basejoin() and urlparse.urljoin(): # - Both are partial implementations of long-obsolete specs. # - Both accept relative URLs as the base, which no spec allows. # - urllib.basejoin() mishandles the '' and '..' references. # - If the base URL uses a non-hierarchical or relative path, # or if the URL scheme is unrecognized, the result is not # always as expected (partly due to issues in RFC 1808). # - If the authority component of a 'file' URI is empty, # the authority component is removed altogether. If it was # not present, an empty authority component is in the result. # - '.' and '..' segments are not always collapsed as well as they # should be (partly due to issues in RFC 1808). # - Effective Python 2.4, urllib.basejoin() *is* urlparse.urljoin(), # but urlparse.urljoin() is still based on RFC 1808. See also the back python-dev discussions on "urlparse" for examples of people wanting a better/more up-to-date urlparse/urljoin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591035&group_id=5470 From noreply at sourceforge.net Mon Nov 6 00:01:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 15:01:35 -0800 Subject: [ python-Bugs-1590804 ] python: Python/ast.c:541: seq_for_testlist: Assertion Message-ID: Bugs item #1590804, was opened at 2006-11-05 13:13 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590804&group_id=5470 Please note that this message 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: AST Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) Summary: python: Python/ast.c:541: seq_for_testlist: Assertion Initial Comment: When I build Python for debug using --with-pydebug on linux platforms (RHEL3 or FC6) I get the following assertion error when I try to install numpy-1.0: [jmiller at localhost numpy-1.0]$ python setup.py install Running from numpy source directory. python: Python/ast.c:541: seq_for_testlist: Assertion `((n)->n_type) == 326 || ((n)->n_type) == 318 || ((n)->n_type) == 319 || ((n)->n_type) == 300' failed. Abort ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-05 23:01 Message: Logged In: YES user_id=849994 Wasn't that already fixed with #1588287? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-05 22:23 Message: Logged In: YES user_id=21627 Thanks for the report. Attached is a simplified test case, and a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590804&group_id=5470 From noreply at sourceforge.net Mon Nov 6 00:11:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 15:11:31 -0800 Subject: [ python-Bugs-1590804 ] python: Python/ast.c:541: seq_for_testlist: Assertion Message-ID: Bugs item #1590804, was opened at 2006-11-05 14:13 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590804&group_id=5470 Please note that this message 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: AST >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Jay T Miller (jaytmiller) Assigned to: Nobody/Anonymous (nobody) Summary: python: Python/ast.c:541: seq_for_testlist: Assertion Initial Comment: When I build Python for debug using --with-pydebug on linux platforms (RHEL3 or FC6) I get the following assertion error when I try to install numpy-1.0: [jmiller at localhost numpy-1.0]$ python setup.py install Running from numpy source directory. python: Python/ast.c:541: seq_for_testlist: Assertion `((n)->n_type) == 326 || ((n)->n_type) == 318 || ((n)->n_type) == 319 || ((n)->n_type) == 300' failed. Abort ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-06 00:11 Message: Logged In: YES user_id=21627 Indeed; I hadn't updated my tree. Closing as fixed. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-06 00:01 Message: Logged In: YES user_id=849994 Wasn't that already fixed with #1588287? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-05 23:23 Message: Logged In: YES user_id=21627 Thanks for the report. Attached is a simplified test case, and a patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590804&group_id=5470 From noreply at sourceforge.net Mon Nov 6 00:12:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 15:12:50 -0800 Subject: [ python-Bugs-1590592 ] where is zlib??? Message-ID: Bugs item #1590592, was opened at 2006-11-04 20:51 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590592&group_id=5470 Please note that this 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: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: AKap (aleksey_kap) Assigned to: Nobody/Anonymous (nobody) Summary: where is zlib??? Initial Comment: Python2.5 for win32 msi-installer - where are zlib.dll and zlib.pyd ??? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-06 00:12 Message: Logged In: YES user_id=21627 They aren't part of the distribution. Why do you think they should be? zlib is linked into python25.dll. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590592&group_id=5470 From noreply at sourceforge.net Mon Nov 6 01:41:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 16:41:41 -0800 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 16:43 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 Please note that this message 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 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-05 16:41 Message: Logged In: YES user_id=33168 What's the status of this patch? It seems like it's ready to checkin. Since this change isn't b/w compatible, should we do anything to fix these in 2.5? For example, bug 1590036. We could add recursion checks one by one, but I'm tempted to ignore 2.5. It seems too little of a gain to fix 2.5 and 2.6 in incompatible ways for such unlikely bugs like these. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-30 17:46 Message: Logged In: YES user_id=357491 OK, new patch, with the check in PyObject_Call() (and thus slot_tp_call() recursion check removed), the addition of PyExc_RecursionErrorInst which is an instance of RuntimeError and a reasonable message set, and PyErr_NormalizeException() checking the recursion depth directly and using PyExc_RecursionErrorInst when the limit is hit. Hopefully this does it. =) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-30 10:06 Message: Logged In: YES user_id=357491 Seems reasonable to me. I will try to cook up a patch after I am done trying to fix the xml_parsers.py crasher. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-30 00:14 Message: Logged In: YES user_id=4771 Looks quite obscure, a hack to avoid the bad effects of the previous hack of temporarily decreasing the recursion depth (which no other piece of code does). I'd be much more confident that I'm looking at correct code if we used a more explicit approach. What about a prebuilt RuntimeError instance with the message "maximum recursion depth exceeded", similar to the prebuilt MemoryError instance? Then at least PyObject_Call() could raise this instance directly, with PyErr_SetObject(). We'd get an already-normalized exception in this way, and remove any need for tstate recursion_depth mangling. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-26 12:31 Message: Logged In: YES user_id=357491 Yes, Armin, that is a rather evil piece of code. =) But I have a possible simple solution. =) If you add a check after the PyExceptionClass_Check() in the 'if' statement that tstate->recursion_depth is greater than 0, you short-circuit the infinite recursion and still get a sensible output. I have attached a patch with my proposed changes for PyObject_Call() and PyErr_NormalizeException() and the remove of the recursion check for slot_tp_call(). The only issue I can see with this is if the recursion_depth check turns out to be too small of a number. But I really doubt that will be an issue since one shouldn't be having a depth of tracebacks greater than the current recursion depth. Let me know what you think of the patch. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-25 02:33 Message: Logged In: YES user_id=4771 Yes, it seems reasonable. You should probably manipulate tstate->recursion_depth directly instead of via the macros, as e.g. ceval.c does. This would fix most crashes here. It would make the attached test17.py segfault, though. This test17 already segfaults a debug build of Python, but not a release build because the recursive PyErr_NormalizeException() is turned into a tail call by gcc. (What, a convoluted mind, mine?) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 14:54 Message: Logged In: YES user_id=357491 I just had an idea, Armin. What if, at the recursive call site in PyErr_NormalizeException(), we called Py_LeaveRecursiveCall() before and Py_EnterRecursiveCall() after? That would keep the recursion limit the same when the normalization was done, but still allow the check in PyObject_Call():: Py_LeaveRecursiveCall(); PyErr_NormalizeException(exc, val, tb); Py_EnterRecursiveCall(""); Since it is an internal call I think it would be safe to "play" with the recursion depth value like this. What do you think? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:57 Message: Logged In: YES user_id=357491 The rev. that Armin checked in was actually r47061. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:53 Message: Logged In: YES user_id=357491 I thought the check was in slot_tp_call and not PyObject_Call. So yeah, I basically forgot. =) The problem with allowing the segfault to stay is that it destroys security in terms of protecting the interpreter, which I am trying to deal with. So leaving random ways to crash the interpreter is currently a no-no for me. I will see if I can come up with another way to fix this issue. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-23 13:05 Message: Logged In: YES user_id=4771 I'd have answer "good idea, go ahead", if it were not for what I found out a few days ago, which is that: * you already checked yourself a Py_EnterRecursiveCall() into PyObject_Call() -- that was in r46806 (I guess you forgot) * I got a case of Python hanging on me in an infinite busy loop, which turned out to be caused by this (!) So I reverted r46806 in r47601, added a test (see log for an explanation), and moved the PyEnter_RecursiveCall() elsewhere, where it still catches the originally intended case, but where it will probably not catch the cases of the present tracker any more. Not sure what to do about it. I'd suggest to be extra careful here; better some extremely obscure and ad-hoc ways to provoke a segfault, rather than busy-loop hangs in previously working programs... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 12:44 Message: Logged In: YES user_id=357491 Do you have any objection to using the Py_EnterRecursiveCall() in PyObject_Call(), Armin, to at least deal with the crashers it fixes? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 13:39 Message: Logged In: YES user_id=593130 Bug submission [ 1267884 ] crash recursive __getattr__ appears to be another example of this problem, so I closed it as a duplicate. If that turns out to be wrong, it should be reopened. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-29 05:23 Message: Logged In: YES user_id=4771 Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the examples so far, with the exception of the "__get__=getattr" one, where we get a strange result instead of a RuntimeError (I suspect careless exception eating is taking place). The main loop in ceval.c doesn't call PyObject_Call() very often: it usually dispatches directly itself for performance, which is exactly what we want here, as recursion from ceval.c is already protected by a Py_EnterRecursiveCall(). So this change has a minor impact on performance. Pystone for example issues only three PyObject_Call() per loop, to call classes. This has an almost-unmeasurable impact ( < 0.4%). Of course I'll think a bit more and search for examples that don't go through PyObject_Call() :-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 06:52 Message: Logged In: YES user_id=4771 When I thought about the same problem for PyPy, I imagined that it would be easy to use the call graph computed by the type inferencer ("annotator"). We would find an algorithm that figures out the minimal number of places that need a Py_EnterRecursiveCall so that every cycle goes through at least one of them. For CPython it might be possible to go down the same path if someone can find a C code analyzer smart enough to provide the required information -- a call graph including indirect calls through function pointers. Not sure it's sane, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-23 06:16 Message: Logged In: YES user_id=6656 I agree with Armin that this could easily be a never ending story. Perhaps it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes. It might have to, because I can't really think of a better way of doing this. The only other approach I know is that of SBCL (a Common Lisp implementation): it mprotects a page at the end of the stack and installs a SIGSEGV handler (and uses sigaltstack) that knows how to abort the current lisp operation. Somehow, I don't think we want to go down this line. Anybody have any other ideas? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-23 06:06 Message: Logged In: YES user_id=21627 It has been a long-time policy that you should not be able to crash the Python interpreter even with malicious code. I think this is a good policy, because it provides people always with a back-trace, which is much easier to analyse than a core dump. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 00:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 14:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 14:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 08:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 19:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Mon Nov 6 05:31:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 20:31:50 -0800 Subject: [ python-Bugs-1591122 ] problem building python in vs8express Message-ID: Bugs item #1591122, was opened at 2006-11-05 20:31 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&group_id=5470 Please note that this 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 Private: No Submitted By: Thomas Southern (thomashsouthern) Assigned to: Nobody/Anonymous (nobody) Summary: problem building python in vs8express Initial Comment: When I tried to build pythoncore in vc++8 express, it worked without a hitch until the link stage when i got an unresolved external _init_types. Python compiles just fine and pythonw compiles up to the link where it comes accross the same error. If I am suppose to contact someone else about my issue please sent me in the wright direction. my email is thomashsouthern at yahoo.com ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&group_id=5470 From noreply at sourceforge.net Mon Nov 6 08:46:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 23:46:46 -0800 Subject: [ python-Bugs-1591122 ] problem building python in vs8express Message-ID: Bugs item #1591122, was opened at 2006-11-06 04:31 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&group_id=5470 Please note that this 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 Private: No Submitted By: Thomas Southern (thomashsouthern) Assigned to: Nobody/Anonymous (nobody) Summary: problem building python in vs8express Initial Comment: When I tried to build pythoncore in vc++8 express, it worked without a hitch until the link stage when i got an unresolved external _init_types. Python compiles just fine and pythonw compiles up to the link where it comes accross the same error. If I am suppose to contact someone else about my issue please sent me in the wright direction. my email is thomashsouthern at yahoo.com ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-06 07:46 Message: Logged In: YES user_id=849994 Which version of the sources are you using? I think this is fixed in the SVN HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&group_id=5470 From noreply at sourceforge.net Mon Nov 6 08:48:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 23:48:51 -0800 Subject: [ python-Bugs-1187437 ] TypeError message on bad iteration is misleading Message-ID: Bugs item #1187437, was opened at 2005-04-21 14:58 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1187437&group_id=5470 Please note that this message 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: Out of Date Priority: 2 Private: No Submitted By: Roy Smith (roysmith) >Assigned to: Georg Brandl (gbrandl) Summary: TypeError message on bad iteration is misleading Initial Comment: >>> for i in 5: ... pass ... Traceback (most recent call last): File "", line 1, in ? TypeError: iteration over non-sequence I know this is kind of a trivial point, but the message "iteration of non-sequence" should really be something like "iteration of non-iterable object", since not all iterable things are sequences. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-06 07:48 Message: Logged In: YES user_id=849994 The message is " object is not iterable" in Python 2.5. ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-06-05 10:46 Message: Logged In: YES user_id=1188172 Seems reasonable to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1187437&group_id=5470 From noreply at sourceforge.net Mon Nov 6 08:50:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 23:50:15 -0800 Subject: [ python-Bugs-1379416 ] email.Header encode() unicode P2.3xP2.4 Message-ID: Bugs item #1379416, was opened at 2005-12-13 11:09 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379416&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jan Novak (xnovakj) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Header encode() unicode P2.3xP2.4 Initial Comment: Python: 2.4 Module: email.Header Method: encode() In some cases returns unicode (example on line 5) 1>> from email.Header import Header 2>> Header(unicode('abc?','iso-8859-2'),'utf-8').encode() '=?utf-8?b?YWJjw6E=?=' 3>> Header('abc','utf-8').encode() '=?utf-8?q?abc?=' 4>> Header(u'abc','utf-8').encode() 'abc' ??? 5>> Header('abc','iso-8859-2').encode() u'=?iso-8859-2?q?abc?=' (P2.4) 6>> Header('abc','iso-8859-2').encode() '=?iso-8859-2?q?abc?=' (P2.3) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379416&group_id=5470 From noreply at sourceforge.net Mon Nov 6 08:50:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 23:50:15 -0800 Subject: [ python-Bugs-1582282 ] email.header decode within word Message-ID: Bugs item #1582282, was opened at 2006-10-22 13:16 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582282&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Tokio Kikuchi (tkikuchi) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.header decode within word Initial Comment: The problem is filed in mailman bug report: http://sourceforge.net/tracker/index.php?func=detail&aid=1578539&group_id=103&atid=100103 While Microsoft Entourage's way of encoding iso-8859-1 text is not compliant with RFC-2047, Python email.header.decode_header should treat this 'word' as a simple us-ascii string and should not parse into series of string/charset list. Sm=?ISO-8859-1?B?9g==?=rg=?ISO-8859-1?B?5Q==?=sbord should be parsed as [('Sm=?ISO-8859-1?B?9rg==?=g=?ISO-8859-1?B?5Q==?=sbord', None)], not as [('Sm', None), ('\xf6', 'iso-8859-1'), ('g', None), ('\xe5', 'iso-8859-1'), ('sbord', None)] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1582282&group_id=5470 From noreply at sourceforge.net Mon Nov 6 08:50:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 23:50:15 -0800 Subject: [ python-Bugs-1372770 ] email.Header should preserve original FWS Message-ID: Bugs item #1372770, was opened at 2005-12-04 10:53 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372770&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nathan Herring (nherring) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Header should preserve original FWS Initial Comment: The Header class describes its operation as using the continuation_ws parameter, prepending the value to continuation lines. This has the byproduct of possibly converting pre-existing FWS in a header, as evidenced by mailman 2.1.6 which exposes the problem. If the Header class is passed pre-existing Header lines, which in the mailman case is from the original message, and, without any manipulation, ask it for the encoded version, it replaces the original folding with the continuation_ws characters. Given that RFC 2822 unfolding consists only of removing CRLFs, exchanging out the FWS characters changes the logical content of a header value. Standard folding of us-ascii text should only consist of introducing line breaks in front of original FWS in the header line. In the case where the encoding of the source string requires multiple adjacent RFC 2047 encoded-words (either due to disparate encodings or text length), then FWS can be freely inserted and is treated as an artifact of the encoding. It is ignored on reading and as such it doesn't affect the logical content of the header value. It's in this latter case that the continuation_ws parameter should be used. e.g., #!/usr/bin/python -d from email.Header import Header s = "Thread-Topic: Use of tabs when folding header lines -- increasing subject\n length as a test\n" print Header(s, 'us-ascii', None, None, '\t') This script will have replaced the space in front of the word "length" with a tab. It should retain that space and not convert it to the continuation_ws character. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1372770&group_id=5470 From noreply at sourceforge.net Mon Nov 6 08:50:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 23:50:15 -0800 Subject: [ python-Bugs-924806 ] email.Header.Header() produces wrong headers with utf8 enc. Message-ID: Bugs item #924806, was opened at 2004-03-28 09:33 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924806&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Andreas Jung (ajung) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Header.Header() produces wrong headers with utf8 enc. Initial Comment: If you pass 'utf8' as encoding to the Header() (e.g. for the subject) then most mailer can not decode the subject because they expect 'utf-8' and not 'utf8'. Maybe there should be a check for this encoding in the code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924806&group_id=5470 From noreply at sourceforge.net Mon Nov 6 08:50:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 05 Nov 2006 23:50:20 -0800 Subject: [ python-Bugs-1590744 ] mail message parsing glitch Message-ID: Bugs item #1590744, was opened at 2006-11-05 09:21 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590744&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Mike (mcspang) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: mail message parsing glitch Initial Comment: There's something wrong with the handling of line continuation in headers. In the attached mbox the 'Message-id' header is read and stored with a leading space. So message_id = ' <9B09D75DF5B3494BA06E6FE478CE9CC10526CFAF at mgtserver3.ontario.int.ec.gc.ca>' when it's first read. If you write this message out to a new mbox, it is written with the leading space and without the newline. THEN, if you read it in AGAIN, the parser ignores the leading space. One of these steps is buggy, I'm not sure which. It seems to me that the value returned by msg['Message_id'] should not change when the file is written then re-read. In the initial read and final reads above the value differs by a space. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590744&group_id=5470 From noreply at sourceforge.net Mon Nov 6 10:23:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 01:23:24 -0800 Subject: [ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not work Message-ID: Bugs item #1579029, was opened at 2006-10-17 17:03 Message generated for change (Comment added) made by thurnerrupert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Martin v. L?wis (loewis) Summary: --disable-sunaudiodev --disable-tk does not work Initial Comment: trying to disable sunaudiodev and tk does not really work in solaris. ./configure --prefix=/usr/local/Python-2.5 --enable- shared --disable-sunaudiodev --disable-tk building 'sunaudiodev' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/sunaudiodev.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/sunaudiodev.o /usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: sun/audioio.h: No such file or directory building '_tkinter' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -DWITH_APPINIT=1 - I/usr/openwin/include -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/_tkinter.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/_tkinter.o In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:96:23: X11/Xlib.h: No such file or directory In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:572: error: syntax error before "Window" /usr/local/include/tk.h:572: error: `Window' declared as function returning a function /usr/local/include/tk.h:575: error: syntax error before "XEvent" /usr/local/include/tk.h:584: error: syntax error before "Tk_ClassCreateProc" /usr/local/include/tk.h:592: error: syntax error before '}' token /usr/local/include/tk.h:678: error: syntax error before "Bool" is it possible to correct this or state clearly in the configure options how to disable it correctly? we also checked the Modules/Setup and both seems commented. ---------------------------------------------------------------------- >Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-06 10:23 Message: Logged In: YES user_id=1597584 i would appreciate if the build completes without errors. i won't care if it attemts to build, but it should figure out that the sunaudiodev is not there. to my knowledge servers do not need that component. and python should not need it too then. do you see any reason why these components are vital for python? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-04 00:25 Message: Logged In: YES user_id=21627 It doesn't build the modules, as it doesn't succeed when attempting to. Why do you want it not to attempt? ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-03 12:56 Message: Logged In: YES user_id=1597584 what do you suggest then to convince the build not to build it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-02 06:40 Message: Logged In: YES user_id=21627 Re: enable/disable: What makes you think "sunaudiodev" and "tk" are valid values for "FEATURE"? configure --help lists the valid values for FEATURE, namely universalsdk, framework, shared, profiling, toolbox-glue, ipv6, and unicode. Re: there is a compilation error. Sure, an error is reported. However, compilation should not fail because of that. Instead, compilation should complete successfully, and just end up not building these modules. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-02 00:31 Message: Logged In: YES user_id=1597584 and there is no X on the server. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:49 Message: Logged In: YES user_id=1597584 and what does that mean? Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:47 Message: Logged In: YES user_id=1597584 because there is a compilation error with both. sunaudio.h seems not to exist on our server, and tk gives other compilation errors. and i have no idea why i would need these modules on our server. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-17 17:43 Message: Logged In: YES user_id=21627 I fail to see a bug here. What makes you think --disable-sunaudiodev --disable-tk exist? ./configure --help does not claim they do. In fact, it is not possible to disable modules. Why do you want that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 From noreply at sourceforge.net Mon Nov 6 10:47:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 01:47:42 -0800 Subject: [ python-Bugs-1591035 ] update urlparse to RFC 3986 Message-ID: Bugs item #1591035, was opened at 2006-11-05 15:27 Message generated for change (Comment added) made by dalke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591035&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andrew Dalke (dalke) Assigned to: Nobody/Anonymous (nobody) Summary: update urlparse to RFC 3986 Initial Comment: urlparse implements RFC 1808. That is strongly out of date. The most recent is RFC 3986. Here is a text from 4Suite # Reasons to avoid using urllib.basejoin() and urlparse.urljoin(): # - Both are partial implementations of long-obsolete specs. # - Both accept relative URLs as the base, which no spec allows. # - urllib.basejoin() mishandles the '' and '..' references. # - If the base URL uses a non-hierarchical or relative path, # or if the URL scheme is unrecognized, the result is not # always as expected (partly due to issues in RFC 1808). # - If the authority component of a 'file' URI is empty, # the authority component is removed altogether. If it was # not present, an empty authority component is in the result. # - '.' and '..' segments are not always collapsed as well as they # should be (partly due to issues in RFC 1808). # - Effective Python 2.4, urllib.basejoin() *is* urlparse.urljoin(), # but urlparse.urljoin() is still based on RFC 1808. See also the back python-dev discussions on "urlparse" for examples of people wanting a better/more up-to-date urlparse/urljoin. ---------------------------------------------------------------------- >Comment By: Andrew Dalke (dalke) Date: 2006-11-06 02:47 Message: Logged In: YES user_id=190903 See also bug 1462525 which has a 'uriparse.py' replacement for urlparse, claiming better compliance. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591035&group_id=5470 From noreply at sourceforge.net Mon Nov 6 12:49:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 03:49:55 -0800 Subject: [ python-Bugs-1591319 ] replace groups doesn't work in this special case Message-ID: Bugs item #1591319, was opened at 2006-11-06 12: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=1591319&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas K. (tomek74) Assigned to: Gustavo Niemeyer (niemeyer) Summary: replace groups doesn't work in this special case Initial Comment: If you have a regular expression like this: ([0-9])([a-z])? matching this string: 1 1a and replacing with this: yx you get what expected: yx yx BUT: If you replace with this: \1\2 you get nothing replaced, because the group \2 doesn't exist for the pattern "1". But it does exist for the pattern "1a"! We have multiple possibilities here: 1.) The string "1" gives no result, because \2 doesn't exist. The string "1a" gives a result, so the output should be: 1a 2.) The sring "1" gives a result, because \2 is handled like an empty string. The string "1a" gives a result, so the output should be: 1 1a I think the case that the sring "1" has no results, but effects the string "1a" wich would normaly have a result, is bad. What are your thoughts on it? Test code: import re # common variables rawstr = r"""([0-9])([a-z])?""" embedded_rawstr = r"""([0-9])([a-z])?""" matchstr = """1 1a""" # method 1: using a compile object compile_obj = re.compile(rawstr) match_obj = compile_obj.search(matchstr) # method 2: using search function (w/ external flags) match_obj = re.search(rawstr, matchstr) # method 3: using search function (w/ embedded flags) match_obj = re.search(embedded_rawstr, matchstr) # Retrieve group(s) from match_obj all_groups = match_obj.groups() # Retrieve group(s) by index group_1 = match_obj.group(1) group_2 = match_obj.group(2) # Replace string newstr = compile_obj.subn('\1\2', 0) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591319&group_id=5470 From noreply at sourceforge.net Mon Nov 6 13:17:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 04:17:03 -0800 Subject: [ python-Bugs-1591319 ] replace groups doesn't work in this special case Message-ID: Bugs item #1591319, was opened at 2006-11-06 11:49 Message generated for change (Comment added) made by niemeyer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591319&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.4 >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Thomas K. (tomek74) Assigned to: Gustavo Niemeyer (niemeyer) Summary: replace groups doesn't work in this special case Initial Comment: If you have a regular expression like this: ([0-9])([a-z])? matching this string: 1 1a and replacing with this: yx you get what expected: yx yx BUT: If you replace with this: \1\2 you get nothing replaced, because the group \2 doesn't exist for the pattern "1". But it does exist for the pattern "1a"! We have multiple possibilities here: 1.) The string "1" gives no result, because \2 doesn't exist. The string "1a" gives a result, so the output should be: 1a 2.) The sring "1" gives a result, because \2 is handled like an empty string. The string "1a" gives a result, so the output should be: 1 1a I think the case that the sring "1" has no results, but effects the string "1a" wich would normaly have a result, is bad. What are your thoughts on it? Test code: import re # common variables rawstr = r"""([0-9])([a-z])?""" embedded_rawstr = r"""([0-9])([a-z])?""" matchstr = """1 1a""" # method 1: using a compile object compile_obj = re.compile(rawstr) match_obj = compile_obj.search(matchstr) # method 2: using search function (w/ external flags) match_obj = re.search(rawstr, matchstr) # method 3: using search function (w/ embedded flags) match_obj = re.search(embedded_rawstr, matchstr) # Retrieve group(s) from match_obj all_groups = match_obj.groups() # Retrieve group(s) by index group_1 = match_obj.group(1) group_2 = match_obj.group(2) # Replace string newstr = compile_obj.subn('\1\2', 0) ---------------------------------------------------------------------- >Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-11-06 12:17 Message: Logged In: YES user_id=7887 Hello Thomas, I don't understand exactly what you mean here. This doesn't work: >>> re.compile("([0-9])([a-z])?").subn(r"<\1\2>", "1 1a") Traceback (most recent call last): ... sre_constants.error: unmatched group And this works fine: >>> re.compile("([0-9])([a-z]?)").subn(r"<\1\2>", "1 1a") ('<1> <1a>', 2) The example code you provided doesn't run here, because 'subn()' is being provided bad data (check http://docs.python.org/lib/node46.html for docs). It's also being passed '\1\2', which is really '\x01\x02', and won't do what you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591319&group_id=5470 From noreply at sourceforge.net Mon Nov 6 18:51:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 09:51:31 -0800 Subject: [ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not work Message-ID: Bugs item #1579029, was opened at 2006-10-17 17:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Martin v. L?wis (loewis) Summary: --disable-sunaudiodev --disable-tk does not work Initial Comment: trying to disable sunaudiodev and tk does not really work in solaris. ./configure --prefix=/usr/local/Python-2.5 --enable- shared --disable-sunaudiodev --disable-tk building 'sunaudiodev' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/sunaudiodev.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/sunaudiodev.o /usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: sun/audioio.h: No such file or directory building '_tkinter' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -DWITH_APPINIT=1 - I/usr/openwin/include -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/_tkinter.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/_tkinter.o In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:96:23: X11/Xlib.h: No such file or directory In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:572: error: syntax error before "Window" /usr/local/include/tk.h:572: error: `Window' declared as function returning a function /usr/local/include/tk.h:575: error: syntax error before "XEvent" /usr/local/include/tk.h:584: error: syntax error before "Tk_ClassCreateProc" /usr/local/include/tk.h:592: error: syntax error before '}' token /usr/local/include/tk.h:678: error: syntax error before "Bool" is it possible to correct this or state clearly in the configure options how to disable it correctly? we also checked the Modules/Setup and both seems commented. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-06 18:51 Message: Logged In: YES user_id=21627 The component isn't vital. It shouldn't be relevant for building sunaudiodev whether an audio device is present in the system, as this device isn't necessary for *building* Python. Instead, presence of /usr/include/sys/audioio.h is necessary. I'm puzzled that this file isn't there (it is part of the core development environment, AFAIK); the build process assumes that the header is present if the system name is "sunos5". ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-06 10:23 Message: Logged In: YES user_id=1597584 i would appreciate if the build completes without errors. i won't care if it attemts to build, but it should figure out that the sunaudiodev is not there. to my knowledge servers do not need that component. and python should not need it too then. do you see any reason why these components are vital for python? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-04 00:25 Message: Logged In: YES user_id=21627 It doesn't build the modules, as it doesn't succeed when attempting to. Why do you want it not to attempt? ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-03 12:56 Message: Logged In: YES user_id=1597584 what do you suggest then to convince the build not to build it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-02 06:40 Message: Logged In: YES user_id=21627 Re: enable/disable: What makes you think "sunaudiodev" and "tk" are valid values for "FEATURE"? configure --help lists the valid values for FEATURE, namely universalsdk, framework, shared, profiling, toolbox-glue, ipv6, and unicode. Re: there is a compilation error. Sure, an error is reported. However, compilation should not fail because of that. Instead, compilation should complete successfully, and just end up not building these modules. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-02 00:31 Message: Logged In: YES user_id=1597584 and there is no X on the server. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:49 Message: Logged In: YES user_id=1597584 and what does that mean? Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:47 Message: Logged In: YES user_id=1597584 because there is a compilation error with both. sunaudio.h seems not to exist on our server, and tk gives other compilation errors. and i have no idea why i would need these modules on our server. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-17 17:43 Message: Logged In: YES user_id=21627 I fail to see a bug here. What makes you think --disable-sunaudiodev --disable-tk exist? ./configure --help does not claim they do. In fact, it is not possible to disable modules. Why do you want that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 From noreply at sourceforge.net Mon Nov 6 22:34:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 13:34:31 -0800 Subject: [ python-Bugs-1590864 ] subprocess deadlock Message-ID: Bugs item #1590864, was opened at 2006-11-05 11:06 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590864&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Michael Tsai (michaeltsai) >Assigned to: Peter ?strand (astrand) Summary: subprocess deadlock Initial Comment: When I use subprocess.py from a child thread, sometimes it deadlocks. I determined that the new process is blocked during an import: #0 0x90024427 in semaphore_wait_signal_trap () #1 0x90028414 in pthread_cond_wait () #2 0x004c77bf in PyThread_acquire_lock (lock=0x3189a0, waitflag=1) at Python/thread_pthread.h:452 #3 0x004ae2a6 in lock_import () at Python/import.c:266 #4 0x004b24be in PyImport_ImportModuleLevel (name=0xaad74 "errno", globals=0xbaed0, locals=0x502aa0, fromlist=0xc1378, level=-1) at Python/import.c:2054 #5 0x0048d2e2 in builtin___import__ (self=0x0, args=0x53724c90, kwds=0x0) at Python/bltinmodule.c:47 #6 0x0040decb in PyObject_Call (func=0xa94b8, arg=0x53724c90, kw=0x0) at Objects/abstract.c:1860 and that the code in question is in os.py: def _execvpe(file, args, env=None): from errno import ENOENT, ENOTDIR I think the problem is that since exec (the C function) hasn't yet been called in the new process, it's inherited from the fork a lock that's already held. The main process will eventually release its copy of the lock, but this will not unlock it in the new process, so it deadlocks. If I change os.py so that it imports the constants outside of _execvpe, the new process no longer blocks in this way. This is on Mac OS X 10.4.8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590864&group_id=5470 From noreply at sourceforge.net Mon Nov 6 22:35:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 13:35:55 -0800 Subject: [ python-Bugs-1566331 ] Bad behaviour in .obuf* Message-ID: Bugs item #1566331, was opened at 2006-09-27 09:19 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566331&group_id=5470 Please note that this 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 Private: No Submitted By: Sam Dennis (samdennis) >Assigned to: Greg Ward (gward) Summary: Bad behaviour in .obuf* Initial Comment: The _ssize() function in ossaudiodev.c (2.4.3, but it's the same in svn) calls SNDCTL_SET_CHANNELS with channels=0 as part of an attempt to determine the total number of samples per second for the current configuration of the audio device, but as far as I can tell this is not guaranteed to act as a query and at least two implementations treat it as a request for a monaural format (the ALSA pcm-oss module and the alsa-oss library). What this can safely be replaced with I don't know; both Linux's OSS drivers and ALSA support SOUND_PCM_READ_CHANNELS but this is not standard to the best of my knowledge. Storing the value returned when the program calls .setfmt or .setparameters may be an option. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566331&group_id=5470 From noreply at sourceforge.net Tue Nov 7 00:27:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 15:27:41 -0800 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 16:43 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 Please note that this message 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 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-11-06 15:27 Message: Logged In: YES user_id=357491 I was waiting on Armin to do a final review, but if you are willing to sign off on it I can check it in. And I agree that it isn't worth backporting to 2.5 because of the hassle. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-05 16:41 Message: Logged In: YES user_id=33168 What's the status of this patch? It seems like it's ready to checkin. Since this change isn't b/w compatible, should we do anything to fix these in 2.5? For example, bug 1590036. We could add recursion checks one by one, but I'm tempted to ignore 2.5. It seems too little of a gain to fix 2.5 and 2.6 in incompatible ways for such unlikely bugs like these. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-30 17:46 Message: Logged In: YES user_id=357491 OK, new patch, with the check in PyObject_Call() (and thus slot_tp_call() recursion check removed), the addition of PyExc_RecursionErrorInst which is an instance of RuntimeError and a reasonable message set, and PyErr_NormalizeException() checking the recursion depth directly and using PyExc_RecursionErrorInst when the limit is hit. Hopefully this does it. =) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-30 10:06 Message: Logged In: YES user_id=357491 Seems reasonable to me. I will try to cook up a patch after I am done trying to fix the xml_parsers.py crasher. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-30 00:14 Message: Logged In: YES user_id=4771 Looks quite obscure, a hack to avoid the bad effects of the previous hack of temporarily decreasing the recursion depth (which no other piece of code does). I'd be much more confident that I'm looking at correct code if we used a more explicit approach. What about a prebuilt RuntimeError instance with the message "maximum recursion depth exceeded", similar to the prebuilt MemoryError instance? Then at least PyObject_Call() could raise this instance directly, with PyErr_SetObject(). We'd get an already-normalized exception in this way, and remove any need for tstate recursion_depth mangling. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-26 12:31 Message: Logged In: YES user_id=357491 Yes, Armin, that is a rather evil piece of code. =) But I have a possible simple solution. =) If you add a check after the PyExceptionClass_Check() in the 'if' statement that tstate->recursion_depth is greater than 0, you short-circuit the infinite recursion and still get a sensible output. I have attached a patch with my proposed changes for PyObject_Call() and PyErr_NormalizeException() and the remove of the recursion check for slot_tp_call(). The only issue I can see with this is if the recursion_depth check turns out to be too small of a number. But I really doubt that will be an issue since one shouldn't be having a depth of tracebacks greater than the current recursion depth. Let me know what you think of the patch. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-25 02:33 Message: Logged In: YES user_id=4771 Yes, it seems reasonable. You should probably manipulate tstate->recursion_depth directly instead of via the macros, as e.g. ceval.c does. This would fix most crashes here. It would make the attached test17.py segfault, though. This test17 already segfaults a debug build of Python, but not a release build because the recursive PyErr_NormalizeException() is turned into a tail call by gcc. (What, a convoluted mind, mine?) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 14:54 Message: Logged In: YES user_id=357491 I just had an idea, Armin. What if, at the recursive call site in PyErr_NormalizeException(), we called Py_LeaveRecursiveCall() before and Py_EnterRecursiveCall() after? That would keep the recursion limit the same when the normalization was done, but still allow the check in PyObject_Call():: Py_LeaveRecursiveCall(); PyErr_NormalizeException(exc, val, tb); Py_EnterRecursiveCall(""); Since it is an internal call I think it would be safe to "play" with the recursion depth value like this. What do you think? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:57 Message: Logged In: YES user_id=357491 The rev. that Armin checked in was actually r47061. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:53 Message: Logged In: YES user_id=357491 I thought the check was in slot_tp_call and not PyObject_Call. So yeah, I basically forgot. =) The problem with allowing the segfault to stay is that it destroys security in terms of protecting the interpreter, which I am trying to deal with. So leaving random ways to crash the interpreter is currently a no-no for me. I will see if I can come up with another way to fix this issue. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-23 13:05 Message: Logged In: YES user_id=4771 I'd have answer "good idea, go ahead", if it were not for what I found out a few days ago, which is that: * you already checked yourself a Py_EnterRecursiveCall() into PyObject_Call() -- that was in r46806 (I guess you forgot) * I got a case of Python hanging on me in an infinite busy loop, which turned out to be caused by this (!) So I reverted r46806 in r47601, added a test (see log for an explanation), and moved the PyEnter_RecursiveCall() elsewhere, where it still catches the originally intended case, but where it will probably not catch the cases of the present tracker any more. Not sure what to do about it. I'd suggest to be extra careful here; better some extremely obscure and ad-hoc ways to provoke a segfault, rather than busy-loop hangs in previously working programs... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 12:44 Message: Logged In: YES user_id=357491 Do you have any objection to using the Py_EnterRecursiveCall() in PyObject_Call(), Armin, to at least deal with the crashers it fixes? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 13:39 Message: Logged In: YES user_id=593130 Bug submission [ 1267884 ] crash recursive __getattr__ appears to be another example of this problem, so I closed it as a duplicate. If that turns out to be wrong, it should be reopened. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-29 05:23 Message: Logged In: YES user_id=4771 Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the examples so far, with the exception of the "__get__=getattr" one, where we get a strange result instead of a RuntimeError (I suspect careless exception eating is taking place). The main loop in ceval.c doesn't call PyObject_Call() very often: it usually dispatches directly itself for performance, which is exactly what we want here, as recursion from ceval.c is already protected by a Py_EnterRecursiveCall(). So this change has a minor impact on performance. Pystone for example issues only three PyObject_Call() per loop, to call classes. This has an almost-unmeasurable impact ( < 0.4%). Of course I'll think a bit more and search for examples that don't go through PyObject_Call() :-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 06:52 Message: Logged In: YES user_id=4771 When I thought about the same problem for PyPy, I imagined that it would be easy to use the call graph computed by the type inferencer ("annotator"). We would find an algorithm that figures out the minimal number of places that need a Py_EnterRecursiveCall so that every cycle goes through at least one of them. For CPython it might be possible to go down the same path if someone can find a C code analyzer smart enough to provide the required information -- a call graph including indirect calls through function pointers. Not sure it's sane, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-23 06:16 Message: Logged In: YES user_id=6656 I agree with Armin that this could easily be a never ending story. Perhaps it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes. It might have to, because I can't really think of a better way of doing this. The only other approach I know is that of SBCL (a Common Lisp implementation): it mprotects a page at the end of the stack and installs a SIGSEGV handler (and uses sigaltstack) that knows how to abort the current lisp operation. Somehow, I don't think we want to go down this line. Anybody have any other ideas? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-23 06:06 Message: Logged In: YES user_id=21627 It has been a long-time policy that you should not be able to crash the Python interpreter even with malicious code. I think this is a good policy, because it provides people always with a back-trace, which is much easier to analyse than a core dump. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 00:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 14:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 14:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 08:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 19:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Tue Nov 7 00:58:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 15:58:53 -0800 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 16:43 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 Please note that this message 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 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-06 15:58 Message: Logged In: YES user_id=33168 Armin mentioned in the other bug that if this patch fixes that too (class ... __getattr__ = getattr), this patch should be applied. It seems to be generally in the right direction. I did review the patch and couldn't find any issues. I'm sure Armin will speak up if he disagrees. So go ahead and check in when you are ready. Don't forget to move all the crashers tests into the real test suites and include tests for getattr/hasattr from the other bug report. Thanks! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-11-06 15:27 Message: Logged In: YES user_id=357491 I was waiting on Armin to do a final review, but if you are willing to sign off on it I can check it in. And I agree that it isn't worth backporting to 2.5 because of the hassle. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-05 16:41 Message: Logged In: YES user_id=33168 What's the status of this patch? It seems like it's ready to checkin. Since this change isn't b/w compatible, should we do anything to fix these in 2.5? For example, bug 1590036. We could add recursion checks one by one, but I'm tempted to ignore 2.5. It seems too little of a gain to fix 2.5 and 2.6 in incompatible ways for such unlikely bugs like these. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-30 17:46 Message: Logged In: YES user_id=357491 OK, new patch, with the check in PyObject_Call() (and thus slot_tp_call() recursion check removed), the addition of PyExc_RecursionErrorInst which is an instance of RuntimeError and a reasonable message set, and PyErr_NormalizeException() checking the recursion depth directly and using PyExc_RecursionErrorInst when the limit is hit. Hopefully this does it. =) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-30 10:06 Message: Logged In: YES user_id=357491 Seems reasonable to me. I will try to cook up a patch after I am done trying to fix the xml_parsers.py crasher. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-30 00:14 Message: Logged In: YES user_id=4771 Looks quite obscure, a hack to avoid the bad effects of the previous hack of temporarily decreasing the recursion depth (which no other piece of code does). I'd be much more confident that I'm looking at correct code if we used a more explicit approach. What about a prebuilt RuntimeError instance with the message "maximum recursion depth exceeded", similar to the prebuilt MemoryError instance? Then at least PyObject_Call() could raise this instance directly, with PyErr_SetObject(). We'd get an already-normalized exception in this way, and remove any need for tstate recursion_depth mangling. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-26 12:31 Message: Logged In: YES user_id=357491 Yes, Armin, that is a rather evil piece of code. =) But I have a possible simple solution. =) If you add a check after the PyExceptionClass_Check() in the 'if' statement that tstate->recursion_depth is greater than 0, you short-circuit the infinite recursion and still get a sensible output. I have attached a patch with my proposed changes for PyObject_Call() and PyErr_NormalizeException() and the remove of the recursion check for slot_tp_call(). The only issue I can see with this is if the recursion_depth check turns out to be too small of a number. But I really doubt that will be an issue since one shouldn't be having a depth of tracebacks greater than the current recursion depth. Let me know what you think of the patch. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-25 02:33 Message: Logged In: YES user_id=4771 Yes, it seems reasonable. You should probably manipulate tstate->recursion_depth directly instead of via the macros, as e.g. ceval.c does. This would fix most crashes here. It would make the attached test17.py segfault, though. This test17 already segfaults a debug build of Python, but not a release build because the recursive PyErr_NormalizeException() is turned into a tail call by gcc. (What, a convoluted mind, mine?) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 14:54 Message: Logged In: YES user_id=357491 I just had an idea, Armin. What if, at the recursive call site in PyErr_NormalizeException(), we called Py_LeaveRecursiveCall() before and Py_EnterRecursiveCall() after? That would keep the recursion limit the same when the normalization was done, but still allow the check in PyObject_Call():: Py_LeaveRecursiveCall(); PyErr_NormalizeException(exc, val, tb); Py_EnterRecursiveCall(""); Since it is an internal call I think it would be safe to "play" with the recursion depth value like this. What do you think? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:57 Message: Logged In: YES user_id=357491 The rev. that Armin checked in was actually r47061. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 13:53 Message: Logged In: YES user_id=357491 I thought the check was in slot_tp_call and not PyObject_Call. So yeah, I basically forgot. =) The problem with allowing the segfault to stay is that it destroys security in terms of protecting the interpreter, which I am trying to deal with. So leaving random ways to crash the interpreter is currently a no-no for me. I will see if I can come up with another way to fix this issue. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-23 13:05 Message: Logged In: YES user_id=4771 I'd have answer "good idea, go ahead", if it were not for what I found out a few days ago, which is that: * you already checked yourself a Py_EnterRecursiveCall() into PyObject_Call() -- that was in r46806 (I guess you forgot) * I got a case of Python hanging on me in an infinite busy loop, which turned out to be caused by this (!) So I reverted r46806 in r47601, added a test (see log for an explanation), and moved the PyEnter_RecursiveCall() elsewhere, where it still catches the originally intended case, but where it will probably not catch the cases of the present tracker any more. Not sure what to do about it. I'd suggest to be extra careful here; better some extremely obscure and ad-hoc ways to provoke a segfault, rather than busy-loop hangs in previously working programs... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 12:44 Message: Logged In: YES user_id=357491 Do you have any objection to using the Py_EnterRecursiveCall() in PyObject_Call(), Armin, to at least deal with the crashers it fixes? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 13:39 Message: Logged In: YES user_id=593130 Bug submission [ 1267884 ] crash recursive __getattr__ appears to be another example of this problem, so I closed it as a duplicate. If that turns out to be wrong, it should be reopened. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-29 05:23 Message: Logged In: YES user_id=4771 Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the examples so far, with the exception of the "__get__=getattr" one, where we get a strange result instead of a RuntimeError (I suspect careless exception eating is taking place). The main loop in ceval.c doesn't call PyObject_Call() very often: it usually dispatches directly itself for performance, which is exactly what we want here, as recursion from ceval.c is already protected by a Py_EnterRecursiveCall(). So this change has a minor impact on performance. Pystone for example issues only three PyObject_Call() per loop, to call classes. This has an almost-unmeasurable impact ( < 0.4%). Of course I'll think a bit more and search for examples that don't go through PyObject_Call() :-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 06:52 Message: Logged In: YES user_id=4771 When I thought about the same problem for PyPy, I imagined that it would be easy to use the call graph computed by the type inferencer ("annotator"). We would find an algorithm that figures out the minimal number of places that need a Py_EnterRecursiveCall so that every cycle goes through at least one of them. For CPython it might be possible to go down the same path if someone can find a C code analyzer smart enough to provide the required information -- a call graph including indirect calls through function pointers. Not sure it's sane, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-23 06:16 Message: Logged In: YES user_id=6656 I agree with Armin that this could easily be a never ending story. Perhaps it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes. It might have to, because I can't really think of a better way of doing this. The only other approach I know is that of SBCL (a Common Lisp implementation): it mprotects a page at the end of the stack and installs a SIGSEGV handler (and uses sigaltstack) that knows how to abort the current lisp operation. Somehow, I don't think we want to go down this line. Anybody have any other ideas? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-23 06:06 Message: Logged In: YES user_id=21627 It has been a long-time policy that you should not be able to crash the Python interpreter even with malicious code. I think this is a good policy, because it provides people always with a back-trace, which is much easier to analyse than a core dump. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 00:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 14:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 14:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 08:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-18 19:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Tue Nov 7 01:59:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 16:59:52 -0800 Subject: [ python-Bugs-1591122 ] problem building python in vs8express Message-ID: Bugs item #1591122, was opened at 2006-11-05 20:31 Message generated for change (Comment added) made by thomashsouthern You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&group_id=5470 Please note that this 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 Private: No Submitted By: Thomas Southern (thomashsouthern) Assigned to: Nobody/Anonymous (nobody) Summary: problem building python in vs8express Initial Comment: When I tried to build pythoncore in vc++8 express, it worked without a hitch until the link stage when i got an unresolved external _init_types. Python compiles just fine and pythonw compiles up to the link where it comes accross the same error. If I am suppose to contact someone else about my issue please sent me in the wright direction. my email is thomashsouthern at yahoo.com ---------------------------------------------------------------------- >Comment By: Thomas Southern (thomashsouthern) Date: 2006-11-06 16:59 Message: Logged In: YES user_id=1638546 I am using python 2.5 ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-05 23:46 Message: Logged In: YES user_id=849994 Which version of the sources are you using? I think this is fixed in the SVN HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&group_id=5470 From noreply at sourceforge.net Tue Nov 7 04:08:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 19:08:03 -0800 Subject: [ python-Bugs-1591774 ] Urllib2.urlopen() raises OSError w/bad HTTP Location header Message-ID: Bugs item #1591774, was opened at 2006-11-07 03: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=1591774&group_id=5470 Please note that this 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 Private: No Submitted By: nikitathespider (nikitathespider) Assigned to: Nobody/Anonymous (nobody) Summary: Urllib2.urlopen() raises OSError w/bad HTTP Location header Initial Comment: The documentation for urllib2.urlopen() says that it "[r]aises URLError on errors". But if urllib2 requests a resource from a (misconfigured) Web server and that server returns 302 response with the Location header set to "file:", urlopen raises "OSError: [Errno 2] No such file or directory: ''". I have seen such a misconfiguration in the wild; I've also created a URL on my server that reproduces the problem in case the real-world URL disappears or is fixed. Both URLs are in the attachment with code to reproduce the problem. I can recreate this under Python 2.3 - 2.5 under Mac OS X, FreeBSD and Win2k. I would be satisfied if the module simply followed the documentation and actually returned URLError. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591774&group_id=5470 From noreply at sourceforge.net Tue Nov 7 04:59:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 19:59:58 -0800 Subject: [ python-Bugs-1570255 ] redirected cookies Message-ID: Bugs item #1570255, was opened at 2006-10-04 09:37 Message generated for change (Comment added) made by hans_moleman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570255&group_id=5470 Please note that this 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 Private: No Submitted By: hans_moleman (hans_moleman) Assigned to: Nobody/Anonymous (nobody) Summary: redirected cookies Initial Comment: Cookies are not resend when a redirect is requested. Blurb: I've been trying to get a response off a server using Python. The response so far differs from the response using Firefox. In Python, I have set headers and cookies the way Firefox does it. I noticed that the server accepts the POST request, and redirects the client to another address with the result on it. This happens both with Python and Firefox correctly. Cookie handling differs though: The Python client, when redirected, using the standard redirect handler, does not resend its cookies to the redirected address. Firefox does resend the cookies from the original request. When I redefine the redirect handler and code it so that it adds the cookies from the original request, the response is the same as Firefox's response. This confirms then that resending cookies is required to get the server to respond correctly. Is the default Python redirection cookie policy different from Firefox's policy? Could we improve the default redirection handler to work like Firefox? Is it a bug? I noticed an old open bug report 511786, that looks very much like this problem. It suggests it is fixed. Cheers Hans Moleman. ---------------------------------------------------------------------- >Comment By: hans_moleman (hans_moleman) Date: 2006-11-07 16:59 Message: Logged In: YES user_id=1610873 I believe that a bit of coding is missing. When a cookie is added in 'add_cookie_header' in cookielib.py, it is added under the request.unredirected_hdrs. Line 1317. When a request is resend after a redirect request in 'redirect_request' in urllib2.py, the request.headers are used. Line 509. Additional coding is required that moves cookies from 'unredirected_hdrs' to 'headers' if the domain of the original request matches the domain of the redirected request. I've used http://www.w3.org/Protocols/rfc2109/rfc2109 for that. No idea if that rfc is still current though. ---------------------------------------------------------------------- Comment By: hans_moleman (hans_moleman) Date: 2006-10-30 07:53 Message: Logged In: YES user_id=1610873 OK. I'll have a look at that. Thanks for the pointers. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-10-28 01:16 Message: Logged In: YES user_id=11375 Given the sensitive data in your script, it's certainly best to not post it. You'll have to dig into urllib2 yourself, I think. Start by looking at the code in redirect_request(), around line 520 of urllib2.py, and adding some debug prints. Print out the contents of req.headers; is the cookie line in there? Change the __init__ of AbstractHTTPHandler to default debuglevel to 1, not 0; this will print out all the HTTP lines being sent and received. ---------------------------------------------------------------------- Comment By: hans_moleman (hans_moleman) Date: 2006-10-27 17:20 Message: Logged In: YES user_id=1610873 I am using this script to obtain monthly internet usage statistics from my ISP. My ISP provides a screen via HTTPS, to enter a usercode and password, after which the usage statistics are displayed on a different address. I cannot send this script with my usercode and password. My ISP might not like me doing this either. Therefore I'll try to find another server that behaves similarly, and send you that. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-10-27 09:16 Message: Logged In: YES user_id=11375 More detail is needed to figure out if there's a problem; can you give a sample URL to exhibit the problem? can you provide your code? From the description, it's unclear if this might be a bug in the handling of redirects or in the CookieProcessor class. The bug in 511786 is still fixed; that bug includes sample code, so I could check it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570255&group_id=5470 From noreply at sourceforge.net Tue Nov 7 05:33:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 20:33:06 -0800 Subject: [ python-Bugs-1202533 ] a bunch of infinite C recursions Message-ID: Bugs item #1202533, was opened at 2005-05-15 23:43 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 Please note that this message 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 Private: No Submitted By: Armin Rigo (arigo) Assigned to: Armin Rigo (arigo) Summary: a bunch of infinite C recursions Initial Comment: There is a general way to cause unchecked infinite recursion at the C level, and I have no clue at the moment how it could be reasonably fixed. The idea is to define special __xxx__ methods in such a way that no Python code is actually called before they invoke more special methods (e.g. themselves). >>> class A: pass >>> A.__mul__=new.instancemethod(operator.mul,None,A) >>> A()*2 Segmentation fault ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-11-07 04:33 Message: Logged In: YES user_id=4771 Yes, the patch fixes the other bug too. It looks ready to be checked in (the examples should be added as tests). All the crashers/infinite_rec_*.py now pass, but infinite_rec_2 produces no output instead of a RuntimeError. This is probably an unrelated problem swallowing the exception silently... ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-06 23:58 Message: Logged In: YES user_id=33168 Armin mentioned in the other bug that if this patch fixes that too (class ... __getattr__ = getattr), this patch should be applied. It seems to be generally in the right direction. I did review the patch and couldn't find any issues. I'm sure Armin will speak up if he disagrees. So go ahead and check in when you are ready. Don't forget to move all the crashers tests into the real test suites and include tests for getattr/hasattr from the other bug report. Thanks! ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-11-06 23:27 Message: Logged In: YES user_id=357491 I was waiting on Armin to do a final review, but if you are willing to sign off on it I can check it in. And I agree that it isn't worth backporting to 2.5 because of the hassle. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-06 00:41 Message: Logged In: YES user_id=33168 What's the status of this patch? It seems like it's ready to checkin. Since this change isn't b/w compatible, should we do anything to fix these in 2.5? For example, bug 1590036. We could add recursion checks one by one, but I'm tempted to ignore 2.5. It seems too little of a gain to fix 2.5 and 2.6 in incompatible ways for such unlikely bugs like these. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-07-01 00:46 Message: Logged In: YES user_id=357491 OK, new patch, with the check in PyObject_Call() (and thus slot_tp_call() recursion check removed), the addition of PyExc_RecursionErrorInst which is an instance of RuntimeError and a reasonable message set, and PyErr_NormalizeException() checking the recursion depth directly and using PyExc_RecursionErrorInst when the limit is hit. Hopefully this does it. =) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-30 17:06 Message: Logged In: YES user_id=357491 Seems reasonable to me. I will try to cook up a patch after I am done trying to fix the xml_parsers.py crasher. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-30 07:14 Message: Logged In: YES user_id=4771 Looks quite obscure, a hack to avoid the bad effects of the previous hack of temporarily decreasing the recursion depth (which no other piece of code does). I'd be much more confident that I'm looking at correct code if we used a more explicit approach. What about a prebuilt RuntimeError instance with the message "maximum recursion depth exceeded", similar to the prebuilt MemoryError instance? Then at least PyObject_Call() could raise this instance directly, with PyErr_SetObject(). We'd get an already-normalized exception in this way, and remove any need for tstate recursion_depth mangling. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-26 19:31 Message: Logged In: YES user_id=357491 Yes, Armin, that is a rather evil piece of code. =) But I have a possible simple solution. =) If you add a check after the PyExceptionClass_Check() in the 'if' statement that tstate->recursion_depth is greater than 0, you short-circuit the infinite recursion and still get a sensible output. I have attached a patch with my proposed changes for PyObject_Call() and PyErr_NormalizeException() and the remove of the recursion check for slot_tp_call(). The only issue I can see with this is if the recursion_depth check turns out to be too small of a number. But I really doubt that will be an issue since one shouldn't be having a depth of tracebacks greater than the current recursion depth. Let me know what you think of the patch. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-25 09:33 Message: Logged In: YES user_id=4771 Yes, it seems reasonable. You should probably manipulate tstate->recursion_depth directly instead of via the macros, as e.g. ceval.c does. This would fix most crashes here. It would make the attached test17.py segfault, though. This test17 already segfaults a debug build of Python, but not a release build because the recursive PyErr_NormalizeException() is turned into a tail call by gcc. (What, a convoluted mind, mine?) ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 21:54 Message: Logged In: YES user_id=357491 I just had an idea, Armin. What if, at the recursive call site in PyErr_NormalizeException(), we called Py_LeaveRecursiveCall() before and Py_EnterRecursiveCall() after? That would keep the recursion limit the same when the normalization was done, but still allow the check in PyObject_Call():: Py_LeaveRecursiveCall(); PyErr_NormalizeException(exc, val, tb); Py_EnterRecursiveCall(""); Since it is an internal call I think it would be safe to "play" with the recursion depth value like this. What do you think? ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 20:57 Message: Logged In: YES user_id=357491 The rev. that Armin checked in was actually r47061. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 20:53 Message: Logged In: YES user_id=357491 I thought the check was in slot_tp_call and not PyObject_Call. So yeah, I basically forgot. =) The problem with allowing the segfault to stay is that it destroys security in terms of protecting the interpreter, which I am trying to deal with. So leaving random ways to crash the interpreter is currently a no-no for me. I will see if I can come up with another way to fix this issue. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2006-06-23 20:05 Message: Logged In: YES user_id=4771 I'd have answer "good idea, go ahead", if it were not for what I found out a few days ago, which is that: * you already checked yourself a Py_EnterRecursiveCall() into PyObject_Call() -- that was in r46806 (I guess you forgot) * I got a case of Python hanging on me in an infinite busy loop, which turned out to be caused by this (!) So I reverted r46806 in r47601, added a test (see log for an explanation), and moved the PyEnter_RecursiveCall() elsewhere, where it still catches the originally intended case, but where it will probably not catch the cases of the present tracker any more. Not sure what to do about it. I'd suggest to be extra careful here; better some extremely obscure and ad-hoc ways to provoke a segfault, rather than busy-loop hangs in previously working programs... ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-06-23 19:44 Message: Logged In: YES user_id=357491 Do you have any objection to using the Py_EnterRecursiveCall() in PyObject_Call(), Armin, to at least deal with the crashers it fixes? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-09-01 20:39 Message: Logged In: YES user_id=593130 Bug submission [ 1267884 ] crash recursive __getattr__ appears to be another example of this problem, so I closed it as a duplicate. If that turns out to be wrong, it should be reopened. ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-29 12:23 Message: Logged In: YES user_id=4771 Adding a Py_EnterRecursiveCall() in PyObject_Call() seems to fix all the examples so far, with the exception of the "__get__=getattr" one, where we get a strange result instead of a RuntimeError (I suspect careless exception eating is taking place). The main loop in ceval.c doesn't call PyObject_Call() very often: it usually dispatches directly itself for performance, which is exactly what we want here, as recursion from ceval.c is already protected by a Py_EnterRecursiveCall(). So this change has a minor impact on performance. Pystone for example issues only three PyObject_Call() per loop, to call classes. This has an almost-unmeasurable impact ( < 0.4%). Of course I'll think a bit more and search for examples that don't go through PyObject_Call() :-) ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-23 13:52 Message: Logged In: YES user_id=4771 When I thought about the same problem for PyPy, I imagined that it would be easy to use the call graph computed by the type inferencer ("annotator"). We would find an algorithm that figures out the minimal number of places that need a Py_EnterRecursiveCall so that every cycle goes through at least one of them. For CPython it might be possible to go down the same path if someone can find a C code analyzer smart enough to provide the required information -- a call graph including indirect calls through function pointers. Not sure it's sane, though. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2005-05-23 13:16 Message: Logged In: YES user_id=6656 I agree with Armin that this could easily be a never ending story. Perhaps it would suffice to sprinkle Py_EnterRecursiveCall around as we find holes. It might have to, because I can't really think of a better way of doing this. The only other approach I know is that of SBCL (a Common Lisp implementation): it mprotects a page at the end of the stack and installs a SIGSEGV handler (and uses sigaltstack) that knows how to abort the current lisp operation. Somehow, I don't think we want to go down this line. Anybody have any other ideas? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-23 13:06 Message: Logged In: YES user_id=21627 It has been a long-time policy that you should not be able to crash the Python interpreter even with malicious code. I think this is a good policy, because it provides people always with a back-trace, which is much easier to analyse than a core dump. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-05-23 07:41 Message: Logged In: YES user_id=341410 I personally think that the CPython runtime should make a best-effort to not crash when running code that makes sense. But when CPython is running on input that is nonsensical (in each of the examples that Armin provides, no return value could make sense), I think that as long as the behavior is stated clearly, it is sufficient. Certainly it would be nice if CPython did not crash in such cases, but I don't know if the performance penalty and code maintenance outweigh the cases where users write bad code. Perhaps a compile-time option, enabled by default based on whether or not we want a safer or faster CPython. Of course maintenance is still a chore, and it is one additional set of calls that C extension writers may need to be aware of (if their code can be recursively called, and they want to participate in the infinite recursion detection). ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-20 21:46 Message: Logged In: YES user_id=4771 Yes, but I'm concerned that we would need to add it really really many places, and probably forget some even then. E.g. I just thought about: lst = [apply] lst.append(lst) apply(*lst) It seems a bit hopeless, honestly... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-05-20 21:22 Message: Logged In: YES user_id=21627 Wouldn't adding Py_EnterRecursiveCall into many places solve the problem? ---------------------------------------------------------------------- Comment By: Armin Rigo (arigo) Date: 2005-05-19 15:05 Message: Logged In: YES user_id=4771 This is not about the new module. The same example can be written as: import types class A: pass A.__mul__ = types.MethodType(operator.mul, None, A) If this still looks essentially like an indirect way of using the new module, here is another example: class A(str): __get__ = getattr a = A('a') A.a = a a.a Or, as I just found out, new-style classes are again vulnerable to the older example based __call__, which was fixed for old-style classes: class A(object): pass A.__call__ = A() A()() I'm not denying that these examples look convoluted :-) My point here is that we can basically build a lot of examples based only on core (if not necessarily widely understood) language features. It appears to go against the basic hope that CPython cannot be crashed as long as you don't use features explicitely marked as dangerous. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-19 02:02 Message: Logged In: YES user_id=593130 On Windows, this caused the interactive window to just disappear.so I suspect something similar occurred. New is a known dangerous, use at your own risk, implementation specific module whose use, like byte code hacking, is outside the language proper. Both bypass normal object creation syntax and its checks and both can create invalid objects. A hold-your- hand inplementation would not give such access to internals. Lib Ref 3.28 says "This module provides a low-level interface to the interpreter, so care must be exercised when using this module. It is possible to supply non-sensical arguments which crash the interpreter when the object is used." Should more or different be said? If not, I suspect this should be closed as 'won't fix', as in 'won't remove the inherently dangerous new module'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1202533&group_id=5470 From noreply at sourceforge.net Tue Nov 7 07:03:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 22:03:19 -0800 Subject: [ python-Bugs-1531415 ] parsetok.c emits warnings by writing to stderr Message-ID: Bugs item #1531415, was opened at 2006-07-31 07:37 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531415&group_id=5470 Please note that this message 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 Private: No Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: parsetok.c emits warnings by writing to stderr Initial Comment: Warnings should be emitted with the warning system, via PyErr_Warn. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-11-07 17:03 Message: Logged In: YES user_id=29957 Should we change these to all just default to a SyntaxWarning? I agree that just spitting out warnings to stderr is extremely suboptimal. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531415&group_id=5470 From noreply at sourceforge.net Tue Nov 7 07:07:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 06 Nov 2006 22:07:47 -0800 Subject: [ python-Bugs-1531415 ] parsetok.c emits warnings by writing to stderr Message-ID: Bugs item #1531415, was opened at 2006-07-31 07:37 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531415&group_id=5470 Please note that this message 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 Private: No Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: parsetok.c emits warnings by writing to stderr Initial Comment: Warnings should be emitted with the warning system, via PyErr_Warn. ---------------------------------------------------------------------- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-11-07 17:07 Message: Logged In: YES user_id=29957 Neal points out there could be a bootstrapping problem if warnings.py needs to be imported. We could do something like check for 'warnings' in sys.modules, and still default to stderr if it's not been imported. A more thorough fix is to get warnings.py converted to C code, but that's going to be a 2.6 thing, not a 2.5.1 thing. ---------------------------------------------------------------------- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-11-07 17:03 Message: Logged In: YES user_id=29957 Should we change these to all just default to a SyntaxWarning? I agree that just spitting out warnings to stderr is extremely suboptimal. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1531415&group_id=5470 From noreply at sourceforge.net Tue Nov 7 11:36:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 02:36:28 -0800 Subject: [ python-Bugs-1591319 ] replace groups doesn't work in this special case Message-ID: Bugs item #1591319, was opened at 2006-11-06 12:49 Message generated for change (Comment added) made by tomek74 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591319&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.4 Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Thomas K. (tomek74) Assigned to: Gustavo Niemeyer (niemeyer) Summary: replace groups doesn't work in this special case Initial Comment: If you have a regular expression like this: ([0-9])([a-z])? matching this string: 1 1a and replacing with this: yx you get what expected: yx yx BUT: If you replace with this: \1\2 you get nothing replaced, because the group \2 doesn't exist for the pattern "1". But it does exist for the pattern "1a"! We have multiple possibilities here: 1.) The string "1" gives no result, because \2 doesn't exist. The string "1a" gives a result, so the output should be: 1a 2.) The sring "1" gives a result, because \2 is handled like an empty string. The string "1a" gives a result, so the output should be: 1 1a I think the case that the sring "1" has no results, but effects the string "1a" wich would normaly have a result, is bad. What are your thoughts on it? Test code: import re # common variables rawstr = r"""([0-9])([a-z])?""" embedded_rawstr = r"""([0-9])([a-z])?""" matchstr = """1 1a""" # method 1: using a compile object compile_obj = re.compile(rawstr) match_obj = compile_obj.search(matchstr) # method 2: using search function (w/ external flags) match_obj = re.search(rawstr, matchstr) # method 3: using search function (w/ embedded flags) match_obj = re.search(embedded_rawstr, matchstr) # Retrieve group(s) from match_obj all_groups = match_obj.groups() # Retrieve group(s) by index group_1 = match_obj.group(1) group_2 = match_obj.group(2) # Replace string newstr = compile_obj.subn('\1\2', 0) ---------------------------------------------------------------------- >Comment By: Thomas K. (tomek74) Date: 2006-11-07 11:36 Message: Logged In: YES user_id=22427 I verified your code. It works for me, too. Sorry. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-11-06 13:17 Message: Logged In: YES user_id=7887 Hello Thomas, I don't understand exactly what you mean here. This doesn't work: >>> re.compile("([0-9])([a-z])?").subn(r"<\1\2>", "1 1a") Traceback (most recent call last): ... sre_constants.error: unmatched group And this works fine: >>> re.compile("([0-9])([a-z]?)").subn(r"<\1\2>", "1 1a") ('<1> <1a>', 2) The example code you provided doesn't run here, because 'subn()' is being provided bad data (check http://docs.python.org/lib/node46.html for docs). It's also being passed '\1\2', which is really '\x01\x02', and won't do what you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591319&group_id=5470 From noreply at sourceforge.net Tue Nov 7 15:06:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 06:06:16 -0800 Subject: [ python-Bugs-1105286 ] Undocumented implicit strip() in split(None) string method Message-ID: Bugs item #1105286, was opened at 2005-01-19 16:04 Message generated for change (Comment added) made by yohell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: YoHell (yohell) Assigned to: Raymond Hettinger (rhettinger) Summary: Undocumented implicit strip() in split(None) string method Initial Comment: Hi! I noticed that the string method split() first does an implicit strip() before splitting when it's used with no arguments or with None as the separator (sep in the docs). There is no mention of this implicit strip() in the docs. Example 1: s = " word1 word2 " s.split() then returns ['word1', 'word2'] and not ['', 'word1', 'word2', ''] as one might expect. WHY IS THIS BAD? 1. Because it's undocumented. See: http://www.python.org/doc/current/lib/string-methods.html#l2h-197 2. Because it may lead to unexpected behavior in programs. Example 2: FASTA sequence headers are one line descriptors of biological sequences and are on this form: ">" + Identifier + whitespace + free text description. Let sHeader be a Python string containing a FASTA header. One could then use the following syntax to extract the identifier from the header: sID = sHeader[1:].split(None, 1)[0] However, this does not work if sHeader contains a faulty FASTA header where the identifier is missing or consists of whitespace. In that case sID will contain the first word of the free text description, which is not the desired behavior. WHAT SHOULD BE DONE? The implicit strip() should be removed, or at least should programmers be given the option to turn it off. At the very least it should be documented so that programmers have a chance of adapting their code to it. Thank you for an otherwise splendid language! /Joel Hedlund Ph.D. Student IFM Bioinformatics Link?ping University ---------------------------------------------------------------------- >Comment By: YoHell (yohell) Date: 2006-11-07 15:06 Message: Logged In: YES user_id=1008220 I'm opening this again, since the docs still don't reflect the behavior of the method. from the docs: """ If sep is not specified or is None, a different splitting algorithm is applied. First, whitespace characters (spaces, tabs, newlines, returns, and formfeeds) are stripped from both ends. """ This is not true when maxsplit is given. Example: >>> " foo bar ".split(None) ['foo', 'bar'] >>> " foo bar ".split(None, 1) ['foo', 'bar '] Whitespace is obviously not stripping whitespace from the ends of the string before splitting the rest of the string. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 13:51 Message: Logged In: YES user_id=9205 This should probably also be added to rsplit()? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-01-24 08:15 Message: Logged In: YES user_id=593130 To me, the removal of whitespace at the ends (stripping) is consistent with the removal (or collapsing) of extra whitespace in between so that .split() does not return empty words anywhere. Consider: >>> ',1,,2,'.split(',') ['', '1', '', '2', ''] If ' 1 2 '.split() were to return null strings at the beginning and end of the list, then to be consistent, it should also put one in the middle. One can get this by being explicit (mixed WS can be handled by translation): >>> ' 1 2 '.split(' ') ['', '1', '', '2', ''] Having said this, I also agree that the extra words proposed by jj are helpful. BUG?? In 2.2, splitting an empty or whitespace only string produces an empty list [], not a list with a null word ['']. >>> ''.split() [] >>> ' '.split() [] which is what I see as consistent with the rest of the no-null- word behavior. Has this changed since? (Yes, must upgrade.) I could find no indication of such change in either the tracker or CVS. ---------------------------------------------------------------------- Comment By: YoHell (yohell) Date: 2005-01-20 15:59 Message: Logged In: YES user_id=1008220 Brilliant, guys! Thanks again for a superb scripting language, and with documentation to match! Take care! /Joel Hedlund ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-20 15:50 Message: Logged In: YES user_id=80475 The prosposed wording is fine. If there are no objections or concerns, I'll apply it soon. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-01-20 15:28 Message: Logged In: YES user_id=764593 Replacing the quoted line: """ ... If sep is not specified or is None, a different splitting algorithm is applied. First whitespace (spaces, tabs, newlines, returns, and formfeeds) is stripped from both ends. Then words are separated by arbitrary length strings of whitespace characters . Consecutive whitespace delimiters are treated as a single delimiter ("'1 2 3'.split()" returns "['1', '2', '3']"). Splitting an empty (or whitespace- only) string returns "['']". """ ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-20 15:04 Message: Logged In: YES user_id=80475 What new wording do you propose to be added? ---------------------------------------------------------------------- Comment By: YoHell (yohell) Date: 2005-01-20 11:15 Message: Logged In: YES user_id=1008220 In RE to tim_one: > I think the docs for split() under "String Methods" are quite > clear: On the countrary, my friend, and here's why: > """ > ... > If sep is not specified or is None, a different splitting > algorithm is applied. This sentecnce does not say that whitespace will be implicitly stripped from the edges of the string. > Words are separated by arbitrary length strings of whitespace > characters (spaces, tabs, newlines, returns, and formfeeds). Neither does this one. > Consecutive whitespace delimiters are treated as a single delimiter ("'1 > 2 3'.split()" returns "['1', '2', '3']"). And not that one. > Splitting an empty string returns "['']". > """ And that last one does not mention it either. In fact, there is no mention in the docs of how separators on edges of strings are treated by the split method. And furthermore, there is no mention of that s.split(sep) treats them differrently when sep is None than it does otherwise. Example: >>> ",2,".split(',') ['', '2', ''] >>> " 2 ".split() ['2'] This inconsistent behavior is not in line with how beautifully thought out the Python language is otherwise, and how brilliantly everything else is documented on the http://python.org/doc/ documentation pages. > This won't change, because mountains of code rely on this > behavior -- it's probably the single most common use case > for .split(). I thought as much. However - it's would be Really easy for an admin to add a line of documentation to .split() to explain this. That would certainly help make me a happier man, and hopefully others too. Cheers guys! /Joel ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-19 17:56 Message: Logged In: YES user_id=31435 I think the docs for split() under "String Methods" are quite clear: """ ... If sep is not specified or is None, a different splitting algorithm is applied. Words are separated by arbitrary length strings of whitespace characters (spaces, tabs, newlines, returns, and formfeeds). Consecutive whitespace delimiters are treated as a single delimiter ("'1 2 3'.split()" returns "['1', '2', '3']"). Splitting an empty string returns "['']". """ This won't change, because mountains of code rely on this behavior -- it's probably the single most common use case for .split(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 From noreply at sourceforge.net Tue Nov 7 15:06:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 06:06:31 -0800 Subject: [ python-Bugs-1567234 ] unchecked metaclass mro Message-ID: Bugs item #1567234, was opened at 2006-09-28 14:48 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567234&group_id=5470 Please note that this message 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: Wont Fix Priority: 5 Private: No Submitted By: ganges master (gangesmaster) Assigned to: A.M. Kuchling (akuchling) Summary: unchecked metaclass mro Initial Comment: this bug was fixed in python2.5, but it's worth adding to 2.4.4. metaclasses can return an "insane" mro, which confuses the PyXXX_Check checks, and causes memory corruption. Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class crasher(object): ... class __metaclass__(type): ... def mro(self): ... return (str, int, list) ... >>> c = crasher("hello") >>> c # a very strange object '' >>> dir(c) [] >>> c.append(5) # ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-11-07 09:06 Message: Logged In: YES user_id=11375 This bugfix didn't make it into Python 2.4.4, and Anthony Baxter suggests there probably won't be a 2.4.5 release, so I'm closing this bug. Sorry it didn't work out. ---------------------------------------------------------------------- Comment By: ganges master (gangesmaster) Date: 2006-09-29 09:12 Message: Logged In: YES user_id=1406776 i never managed working with svn's or cvs's... i can point you to the official source distribution of 2.4.2: file: typeobject.c function: static int mro_internal(PyTypeObject *type) +-+-+-+-+-+-+-+- mro = lookup_method((PyObject *)type, "mro", &mro_str); if (mro == NULL) return -1; result = PyObject_CallObject(mro, NULL); Py_DECREF(mro); } if (result == NULL) return -1; tuple = PySequence_Tuple(result); +-+-+-+-+-+-+-+-+- python 2.5 (release) added the following check: +-+-+-+-+-+-+-+-+- if (!PyType_IsSubtype(solid, solid_base(t))) { PyErr_Format(PyExc_TypeError, "mro() returned base with unsuitable layout ('%.500s')", t->tp_name); +-+-+-+-+-+-+-+-+- that's the best i can do, sorry ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-09-29 08:32 Message: Logged In: YES user_id=11375 Can you please provide a reference to the original bug, or to the revision that fixes the bug in 2.5? + ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1567234&group_id=5470 From noreply at sourceforge.net Tue Nov 7 15:11:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 06:11:18 -0800 Subject: [ python-Bugs-1105286 ] Undocumented implicit strip() in split(None) string method Message-ID: Bugs item #1105286, was opened at 2005-01-19 16:04 Message generated for change (Comment added) made by yohell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: YoHell (yohell) Assigned to: Raymond Hettinger (rhettinger) Summary: Undocumented implicit strip() in split(None) string method Initial Comment: Hi! I noticed that the string method split() first does an implicit strip() before splitting when it's used with no arguments or with None as the separator (sep in the docs). There is no mention of this implicit strip() in the docs. Example 1: s = " word1 word2 " s.split() then returns ['word1', 'word2'] and not ['', 'word1', 'word2', ''] as one might expect. WHY IS THIS BAD? 1. Because it's undocumented. See: http://www.python.org/doc/current/lib/string-methods.html#l2h-197 2. Because it may lead to unexpected behavior in programs. Example 2: FASTA sequence headers are one line descriptors of biological sequences and are on this form: ">" + Identifier + whitespace + free text description. Let sHeader be a Python string containing a FASTA header. One could then use the following syntax to extract the identifier from the header: sID = sHeader[1:].split(None, 1)[0] However, this does not work if sHeader contains a faulty FASTA header where the identifier is missing or consists of whitespace. In that case sID will contain the first word of the free text description, which is not the desired behavior. WHAT SHOULD BE DONE? The implicit strip() should be removed, or at least should programmers be given the option to turn it off. At the very least it should be documented so that programmers have a chance of adapting their code to it. Thank you for an otherwise splendid language! /Joel Hedlund Ph.D. Student IFM Bioinformatics Link?ping University ---------------------------------------------------------------------- >Comment By: YoHell (yohell) Date: 2006-11-07 15:11 Message: Logged In: YES user_id=1008220 *resubmission: grammar corrected* I'm opening this again, since the docs still don't reflect the behavior of the method. from the docs: """ If sep is not specified or is None, a different splitting algorithm is applied. First, whitespace characters (spaces, tabs, newlines, returns, and formfeeds) are stripped from both ends. """ This is not true when maxsplit is given. Example: >>> " foo bar ".split(None) ['foo', 'bar'] >>> " foo bar ".split(None, 1) ['foo', 'bar '] Whitespace is obviously not stripped from the ends before the rest of the string is split. ---------------------------------------------------------------------- Comment By: YoHell (yohell) Date: 2006-11-07 15:06 Message: Logged In: YES user_id=1008220 I'm opening this again, since the docs still don't reflect the behavior of the method. from the docs: """ If sep is not specified or is None, a different splitting algorithm is applied. First, whitespace characters (spaces, tabs, newlines, returns, and formfeeds) are stripped from both ends. """ This is not true when maxsplit is given. Example: >>> " foo bar ".split(None) ['foo', 'bar'] >>> " foo bar ".split(None, 1) ['foo', 'bar '] Whitespace is obviously not stripping whitespace from the ends of the string before splitting the rest of the string. ---------------------------------------------------------------------- Comment By: Wummel (calvin) Date: 2005-01-24 13:51 Message: Logged In: YES user_id=9205 This should probably also be added to rsplit()? ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-01-24 08:15 Message: Logged In: YES user_id=593130 To me, the removal of whitespace at the ends (stripping) is consistent with the removal (or collapsing) of extra whitespace in between so that .split() does not return empty words anywhere. Consider: >>> ',1,,2,'.split(',') ['', '1', '', '2', ''] If ' 1 2 '.split() were to return null strings at the beginning and end of the list, then to be consistent, it should also put one in the middle. One can get this by being explicit (mixed WS can be handled by translation): >>> ' 1 2 '.split(' ') ['', '1', '', '2', ''] Having said this, I also agree that the extra words proposed by jj are helpful. BUG?? In 2.2, splitting an empty or whitespace only string produces an empty list [], not a list with a null word ['']. >>> ''.split() [] >>> ' '.split() [] which is what I see as consistent with the rest of the no-null- word behavior. Has this changed since? (Yes, must upgrade.) I could find no indication of such change in either the tracker or CVS. ---------------------------------------------------------------------- Comment By: YoHell (yohell) Date: 2005-01-20 15:59 Message: Logged In: YES user_id=1008220 Brilliant, guys! Thanks again for a superb scripting language, and with documentation to match! Take care! /Joel Hedlund ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-20 15:50 Message: Logged In: YES user_id=80475 The prosposed wording is fine. If there are no objections or concerns, I'll apply it soon. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2005-01-20 15:28 Message: Logged In: YES user_id=764593 Replacing the quoted line: """ ... If sep is not specified or is None, a different splitting algorithm is applied. First whitespace (spaces, tabs, newlines, returns, and formfeeds) is stripped from both ends. Then words are separated by arbitrary length strings of whitespace characters . Consecutive whitespace delimiters are treated as a single delimiter ("'1 2 3'.split()" returns "['1', '2', '3']"). Splitting an empty (or whitespace- only) string returns "['']". """ ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-01-20 15:04 Message: Logged In: YES user_id=80475 What new wording do you propose to be added? ---------------------------------------------------------------------- Comment By: YoHell (yohell) Date: 2005-01-20 11:15 Message: Logged In: YES user_id=1008220 In RE to tim_one: > I think the docs for split() under "String Methods" are quite > clear: On the countrary, my friend, and here's why: > """ > ... > If sep is not specified or is None, a different splitting > algorithm is applied. This sentecnce does not say that whitespace will be implicitly stripped from the edges of the string. > Words are separated by arbitrary length strings of whitespace > characters (spaces, tabs, newlines, returns, and formfeeds). Neither does this one. > Consecutive whitespace delimiters are treated as a single delimiter ("'1 > 2 3'.split()" returns "['1', '2', '3']"). And not that one. > Splitting an empty string returns "['']". > """ And that last one does not mention it either. In fact, there is no mention in the docs of how separators on edges of strings are treated by the split method. And furthermore, there is no mention of that s.split(sep) treats them differrently when sep is None than it does otherwise. Example: >>> ",2,".split(',') ['', '2', ''] >>> " 2 ".split() ['2'] This inconsistent behavior is not in line with how beautifully thought out the Python language is otherwise, and how brilliantly everything else is documented on the http://python.org/doc/ documentation pages. > This won't change, because mountains of code rely on this > behavior -- it's probably the single most common use case > for .split(). I thought as much. However - it's would be Really easy for an admin to add a line of documentation to .split() to explain this. That would certainly help make me a happier man, and hopefully others too. Cheers guys! /Joel ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2005-01-19 17:56 Message: Logged In: YES user_id=31435 I think the docs for split() under "String Methods" are quite clear: """ ... If sep is not specified or is None, a different splitting algorithm is applied. Words are separated by arbitrary length strings of whitespace characters (spaces, tabs, newlines, returns, and formfeeds). Consecutive whitespace delimiters are treated as a single delimiter ("'1 2 3'.split()" returns "['1', '2', '3']"). Splitting an empty string returns "['']". """ This won't change, because mountains of code rely on this behavior -- it's probably the single most common use case for .split(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470 From noreply at sourceforge.net Tue Nov 7 15:32:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 06:32:45 -0800 Subject: [ python-Bugs-893250 ] curses getkey() crash in raw mode Message-ID: Bugs item #893250, was opened at 2004-02-09 02:11 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893250&group_id=5470 Please note that this 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: Wont Fix Priority: 5 Private: No Submitted By: J. David Lee (bogjohnson) Assigned to: A.M. Kuchling (akuchling) Summary: curses getkey() crash in raw mode Initial Comment: Using python 2.3.3 on gentoo I have the following problem: When calling stdscr.getkey() in raw mode, the program crashes on a terminal resize event. In cooked and cbreak modes, the proper string is returned - "KEY_RESIZE". This problem appeared after upgrading from python 2.3.2, I believe. Below is a quick program that exhibits this behavior on my machine. ####################################################### #!/usr/bin/env python import curses; stdscr = curses.initscr(); curses.raw(); curses.noecho(); stdscr.keypad(1); while(1): stdscr.clear(); stdscr.addstr("Enter key: "); c = stdscr.getkey(); if(c == 'q'): break; stdscr.clear(); stdscr.addstr('"' + c + '"\n\n'); stdscr.addstr("Press any key..."); stdscr.getkey(); curses.noraw(); curses.endwin(); ####################################################### A couple of other notes: 1) No exception is thrown (a try block doesn't catch it). 2) The behavior is the same using the interactive interpreter. 3) The traceback is: File "./keyname", line 19, in ? stdscr.getkey(); _curses.error: no input ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-11-07 09:32 Message: Logged In: YES user_id=11375 After experimenting a bit with the attached test program, it doesn't seem as if this is actually a bug in the module; the ncurses docs themselves are vague on the interaction between signals and a KEY_RESIZE. So I'll close this bug, because it doesn't look like there's anything in Python to fix. ---------------------------------------------------------------------- Comment By: J. David Lee (bogjohnson) Date: 2004-04-20 01:21 Message: Logged In: YES user_id=971407 That Gentoo updated the ncurses library is quite possible. Though the behavior is still incorrect as the documentation says that getkey will return "KEY_RESIZE" on a terminal resize event, and in fact it does in cooked and cbreak modes, but throws an exception when in raw mode (though a terminal resize isn't an exceptional circumstance). Also, a program can't assume that an exception on getkey() is a resize event because an actual exception might occur and need to be dealt with. For the present, though, the workaround is acceptable because a real exception on getkey is very unlikely, as far as I can see. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-04-19 08:45 Message: Logged In: YES user_id=11375 1) and 3) are contradictory; 3 is certainly an exception traceback. When I try the test program on a Debian system, I get the same error, but a try:except: around the getkey() on line 19 lets the program continue running. Nothing in the Python curses module changed between 2.3.3 and 2.3.2. Did gentoo switch to a new revision of the ncurses library, perhaps? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893250&group_id=5470 From noreply at sourceforge.net Tue Nov 7 15:36:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 06:36:37 -0800 Subject: [ python-Bugs-893250 ] curses getkey() crash in raw mode Message-ID: Bugs item #893250, was opened at 2004-02-09 02:11 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893250&group_id=5470 Please note that this 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: Wont Fix Priority: 5 Private: No Submitted By: J. David Lee (bogjohnson) Assigned to: A.M. Kuchling (akuchling) Summary: curses getkey() crash in raw mode Initial Comment: Using python 2.3.3 on gentoo I have the following problem: When calling stdscr.getkey() in raw mode, the program crashes on a terminal resize event. In cooked and cbreak modes, the proper string is returned - "KEY_RESIZE". This problem appeared after upgrading from python 2.3.2, I believe. Below is a quick program that exhibits this behavior on my machine. ####################################################### #!/usr/bin/env python import curses; stdscr = curses.initscr(); curses.raw(); curses.noecho(); stdscr.keypad(1); while(1): stdscr.clear(); stdscr.addstr("Enter key: "); c = stdscr.getkey(); if(c == 'q'): break; stdscr.clear(); stdscr.addstr('"' + c + '"\n\n'); stdscr.addstr("Press any key..."); stdscr.getkey(); curses.noraw(); curses.endwin(); ####################################################### A couple of other notes: 1) No exception is thrown (a try block doesn't catch it). 2) The behavior is the same using the interactive interpreter. 3) The traceback is: File "./keyname", line 19, in ? stdscr.getkey(); _curses.error: no input ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-11-07 09:36 Message: Logged In: YES user_id=11375 Forgot to attach the script I was using. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-11-07 09:32 Message: Logged In: YES user_id=11375 After experimenting a bit with the attached test program, it doesn't seem as if this is actually a bug in the module; the ncurses docs themselves are vague on the interaction between signals and a KEY_RESIZE. So I'll close this bug, because it doesn't look like there's anything in Python to fix. ---------------------------------------------------------------------- Comment By: J. David Lee (bogjohnson) Date: 2004-04-20 01:21 Message: Logged In: YES user_id=971407 That Gentoo updated the ncurses library is quite possible. Though the behavior is still incorrect as the documentation says that getkey will return "KEY_RESIZE" on a terminal resize event, and in fact it does in cooked and cbreak modes, but throws an exception when in raw mode (though a terminal resize isn't an exceptional circumstance). Also, a program can't assume that an exception on getkey() is a resize event because an actual exception might occur and need to be dealt with. For the present, though, the workaround is acceptable because a real exception on getkey is very unlikely, as far as I can see. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2004-04-19 08:45 Message: Logged In: YES user_id=11375 1) and 3) are contradictory; 3 is certainly an exception traceback. When I try the test program on a Debian system, I get the same error, but a try:except: around the getkey() on line 19 lets the program continue running. Nothing in the Python curses module changed between 2.3.3 and 2.3.2. Did gentoo switch to a new revision of the ncurses library, perhaps? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893250&group_id=5470 From noreply at sourceforge.net Tue Nov 7 16:41:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 07:41:54 -0800 Subject: [ python-Bugs-1591122 ] problem building python in vs8express Message-ID: Bugs item #1591122, was opened at 2006-11-06 04:31 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&group_id=5470 Please note that this 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: Pending Resolution: None Priority: 5 Private: No Submitted By: Thomas Southern (thomashsouthern) Assigned to: Nobody/Anonymous (nobody) Summary: problem building python in vs8express Initial Comment: When I tried to build pythoncore in vc++8 express, it worked without a hitch until the link stage when i got an unresolved external _init_types. Python compiles just fine and pythonw compiles up to the link where it comes accross the same error. If I am suppose to contact someone else about my issue please sent me in the wright direction. my email is thomashsouthern at yahoo.com ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-07 15:41 Message: Logged In: YES user_id=849994 So could you please retry with the SVN HEAD? ---------------------------------------------------------------------- Comment By: Thomas Southern (thomashsouthern) Date: 2006-11-07 00:59 Message: Logged In: YES user_id=1638546 I am using python 2.5 ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-06 07:46 Message: Logged In: YES user_id=849994 Which version of the sources are you using? I think this is fixed in the SVN HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&group_id=5470 From noreply at sourceforge.net Tue Nov 7 21:05:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 12:05:35 -0800 Subject: [ python-Bugs-1592241 ] Stepping into a generator throw does not work Message-ID: Bugs item #1592241, was opened at 2006-11-07 12: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=1592241&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Bernhard Mulder (bwmulder) Assigned to: Nobody/Anonymous (nobody) Summary: Stepping into a generator throw does not work Initial Comment: Python version: 2.6 Platform: Windows XP Stepping into a throw of an iterator with the debugger does not work. To reproduce: 1. Run the attached script 2. type 's' for single step once you see the debugger prompt. I am getting this backtrace: File "C:\bwm\Cruiser\play\microthreads\post.py", line 24, in it.throw(E, E()) File "C:\bwm\Cruiser\play\microthreads\post.py", line 7, in f1 (yield (2,(self.f2,(exc_class,)))) File "C:\Python25\lib\bdb.py", line 50, in trace_dispatch return self.dispatch_call(frame, arg) File "C:\Python25\lib\bdb.py", line 79, in dispatch_call self.user_call(frame, arg) File "C:\Python25\lib\pdb.py", line 134, in user_call self.interaction(frame, None) File "C:\Python25\lib\pdb.py", line 185, in interaction self.setup(frame, traceback) File "C:\Python25\lib\pdb.py", line 109, in setup self.stack, self.curindex = self.get_stack(f, t) File "C:\Python25\lib\bdb.py", line 318, in get_stack i = max(0, len(stack) - 1) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1592241&group_id=5470 From noreply at sourceforge.net Wed Nov 8 02:14:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 17:14:11 -0800 Subject: [ python-Bugs-1591122 ] problem building python in vs8express Message-ID: Bugs item #1591122, was opened at 2006-11-05 20:31 Message generated for change (Comment added) made by thomashsouthern You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&group_id=5470 Please note that this 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 Private: No Submitted By: Thomas Southern (thomashsouthern) Assigned to: Nobody/Anonymous (nobody) Summary: problem building python in vs8express Initial Comment: When I tried to build pythoncore in vc++8 express, it worked without a hitch until the link stage when i got an unresolved external _init_types. Python compiles just fine and pythonw compiles up to the link where it comes accross the same error. If I am suppose to contact someone else about my issue please sent me in the wright direction. my email is thomashsouthern at yahoo.com ---------------------------------------------------------------------- >Comment By: Thomas Southern (thomashsouthern) Date: 2006-11-07 17:14 Message: Logged In: YES user_id=1638546 thank you for your responses. after I answered your first question i went in search of the svn head for this project. I started at www.python.org and went to the developement area. I found svn trunk where the files for python 2.6 were located. I appolgize if I appear ignorant but I have never been interested in an open source project enough to want to compile from scratch and maybe even try and see what I could contribute. I don't know if I found the right area. where I did find. I would need to download each file individually. also, the "solution items" with "getbuildinfo.c" was not recognized by the vc++ express compiler. My question is this, am I looking in the correct location for the files I am looking for to build the source myself. also if this brings me out of the preview of the purpose of this thread please direct me to the proper location to continue to ask questions I might have as I try to understand my way around this project. thank you for your patients and help. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-07 07:41 Message: Logged In: YES user_id=849994 So could you please retry with the SVN HEAD? ---------------------------------------------------------------------- Comment By: Thomas Southern (thomashsouthern) Date: 2006-11-06 16:59 Message: Logged In: YES user_id=1638546 I am using python 2.5 ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-05 23:46 Message: Logged In: YES user_id=849994 Which version of the sources are you using? I think this is fixed in the SVN HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&group_id=5470 From noreply at sourceforge.net Wed Nov 8 08:02:59 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 23:02:59 -0800 Subject: [ python-Bugs-1583946 ] SSL "issuer" and "server" names cannot be parsed Message-ID: Bugs item #1583946, was opened at 2006-10-24 18:32 Message generated for change (Comment added) made by nagle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: John Nagle (nagle) Assigned to: Nobody/Anonymous (nobody) Summary: SSL "issuer" and "server" names cannot be parsed Initial Comment: (Python 2.5 library) The Python SSL object offers two methods from obtaining the info from an SSL certificate, "server()" and "issuer()". These return strings. The actual values in the certificate are a series of key /value pairs in ASN.1 binary format. But what "server()" and "issuer()" return are single strings, with the key/value pairs separated by "/". However, "/" is a valid character in certificate data. So parsing such strings is ambiguous, and potentially exploitable. This is more than a theoretical problem. The issuer field of Verisign certificates has a "/" in the middle of a text field: "/O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign". Note the "OU=Terms of use at www.verisign.com/rpa (c)00" with a "/" in the middle of the value field. Oops. Worse, this is potentially exploitable. By ordering a low-level certificate with a "/" in the right place, you can create the illusion (at least for flawed implementations like this one) that the certificate belongs to someone else. Just order a certificate from GoDaddy, enter something like this in the "Name" field "Myphonyname/C=US/ST=California/L=San Jose/O=eBay Inc./OU=Site Operations/CN=signin.ebay.com" and Python code will be spoofed into thinking you're eBay. Fortunately, browsers don't use Python code. The actual bug is in python/trunk/Modules/_ssl.c at if ((self->server_cert = SSL_get_peer_certificate(self->ssl))) { X509_NAME_oneline(X509_get_subject_name(self->server_cert), self->server, X509_NAME_MAXLEN); X509_NAME_oneline(X509_get_issuer_name(self->server_cert), self->issuer, X509_NAME_MAXLEN); The "X509_name_oneline" function takes an X509_NAME structure, which is the certificate system's representation of a list, and flattens it into a printable string. This is a debug function, not one for use in production code. The SSL documentation for "X509_name_oneline" says: "The functions X509_NAME_oneline() and X509_NAME_print() are legacy functions which produce a non standard output form, they don't handle multi character fields and have various quirks and inconsistencies. Their use is strongly discouraged in new applications." What OpenSSL callers are supposed to do is call X509_NAME_entry_count() to get the number of entries in an X509_NAME structure, then get each entry with X509_NAME_get_entry(). A few more calls will obtain the name/value pair from the entry, as UTF8 strings, which should be converted to Python UNICODE strings. OpenSSL has all the proper support, but Python's shim doesn't interface to it correctly. X509_NAME_oneline() doesn't handle Unicode; it converts non-ASCII values to "\xnn" format. Again, it's for debug output only. So what's needed are two new functions for Python's SSL sockets to replace "issuer" and "server". The new functions should return lists of Unicode strings representing the key/value pairs. (A list is needed, not a dictionary; two strings with the same key are both possible and common.) The reason this now matters is that new "high assurance" certs, the ones that tell you how much a site can be trusted, are now being deployed, and to use them effectively, you need that info. Support for them is in Internet Explorer 7, so they're going to be widespread soon. Python needs to catch up. And, of course, this needs to be fixed as part of Unicode support. John Nagle Animats ---------------------------------------------------------------------- >Comment By: John Nagle (nagle) Date: 2006-11-08 07:02 Message: Logged In: YES user_id=5571 I've submitted a request (titled "Request: make X509_NAME_oneline() use same formatter as X509_NAME_print_ex()") to the OpenSSL developers to fix this on their side. If they fix that, delimiters will be escaped per the standard. The OpenSSL people should also export the functionality of getting this information as a UTF8 string, and if they do, Python should use that call as part of Unicode support. Keep this open pending action on the OpenSSL side. Thanks. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-10-27 12:54 Message: Logged In: YES user_id=11375 I've reworded the description in the documentation to say something like this: "Returns a string describing the issuer of the server's certificate. Useful for debugging purposes; do not parse the content of this string because its format can't be parsed unambiguously." For adding new features: please submit a patch. Python's maintainers probably don't use SSL in any sophisticated way and therefore have no idea what shape better SSL/X.509 support would take. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-25 18:05 Message: Logged In: YES user_id=21627 Notice that RFC 2253 has been superceded by RFC 4514 (see my earlier message). However, I really see no reason to fix this: even if the ambiguity problems were fixed, you *still* should not use the issuer and subject names in a security-relevant context. ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2006-10-25 17:26 Message: Logged In: YES user_id=5571 Actually, they don't do what they're "designed to do". According to the Python library documentation for SSL objects, the server method "Returns a string containing the ASN.1 distinguished name identifying the server's certificate. (See below for an example showing what distinguished names look like.)" The example "below" is missing from the documentation, so the documentation gives us no clue of what to expect. There are several standardized representations for ASN.1 information. See "http://www.oss.com/asn1/tutorial/Explain.html" Most are binary. The only standard textual form is "XER", which is an XML representation of ASN.1 encoded information. It's essentially the same representation used for parameters in SOAP. So, given the documentation and the standard, what should be coming out is the XML representation of that data. Here's an entire X.509 certificate in XML: http://www.gnu.org/software/gnutls/manual/html_node/An-X_002e509-certificate.html The "issuer" field can be seen in there. It's awfully bulky. And making SSL dependent on the SOAP module probably isn't desireable. But that's an ASN.1 distinguished name in XML format, per the standard. That's probably not what's wanted by most users, although the ability to retrieve an entire certificate in XML format would be useful. However, there's another standard string encoding, which is defined in RFC2253. This is comma-separated UTF-8 with backslash escapes for special characters. That's reliably parseable. There's an openSSL function, "X509_NAME_print_ex", which does this formatting, but it doesn't output to a string. That's the right mechanism if it can be invoked in some way to yield a string. It should be invoked with flags = ASN1_STRFLGS_RFC2253, which yields a UTF8 string, which of course should become a Python Unicode string. Now if someone can figure out how to get a string, instead of file output, out of OpenSSL's "X509_NAME_print_ex", we're home. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-25 08:38 Message: Logged In: YES user_id=21627 The bug is not in the the server() and issuer() methods (which do exactly what they are meant to do); the bug is in applications which assume that the result of these methods can be parsed. As you point out, it cannot. The functions, as is, don't present a security problem. If their result is presented as-is to the user, the user can determine herself whether she recognizes the entity referred-to in the distinguished name. Notice that it is certainly possible to produce an unambigous string representation of a distinguished name; RFC 4514 specifies an algorithm to do so (for use within LDAP). Also notice that that the SSL module does little to actually support trust: there is no verification of server-side certs, no access to extensions of a certificate, etc. So an application and a user should *not* trust the issuer name it received, anyway (unless there is an independent verification that the server certificate can be trusted). All that said: If you think you need this functionality, please provide a patch to implement it. ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2006-10-24 22:40 Message: Logged In: YES user_id=5571 The problem isn't in the version of OpenSSL used in Python, which is at 0.9.8a. OpenSSL has had the necessary functions for years. But Python isn't using them. It's in "python/trunk/Modules/_ssl.c", as described above. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-10-24 22:05 Message: Logged In: YES user_id=413 Yes OpenSSL 0.9.8d or later should be used for a new binary release. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4343 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3738 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2940 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2937 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470 From noreply at sourceforge.net Wed Nov 8 08:03:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 07 Nov 2006 23:03:19 -0800 Subject: [ python-Bugs-1574310 ] os.popen with os.close gives error message Message-ID: Bugs item #1574310, was opened at 2006-10-10 09:45 Message generated for change (Comment added) made by ronaldoussoren You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574310&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: dtrosset (dtrosset) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen with os.close gives error message Initial Comment: Given the following code: import os child_stdin = os.popen("cat -", "w") old_stdout = os.dup(1) os.close(child_stdin.fileno()) print "foo" os.dup2(old_stdout, 1) os.close(old_stdout) I got these different results depending on the version of python I am using. $ python2.4 -V Python 2.4.4c0 $ python2.4 test.py foo close failed: [Errno 9] Bad file descriptor $ python2.3 -V Python 2.3.5 $ python2.3 test/new/test.py foo My .02$ guess is that underlying file descriptor of child_stdin being closed, when trying to delete this object, it tries again to close it. ---------------------------------------------------------------------- >Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-11-08 08:03 Message: Logged In: YES user_id=580910 IMHO this is "don't do that then" territory. You're poking around in the inside of file objects, you have to be careful if you do that. BTW. What are you trying to accomplish? If you set sys.stdout to child_stdin (e.g. "import sys; sys.stdout = child_stdin"), print will write to the pipe. If you really want to be sure that the C-level variable stdout writes to the pipe: os.dup2(child_stdout.fileno(), 1). You can then close child_stdout, but still have to do the 'os.dup(1)' part if you want to restore the real stdout later on. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574310&group_id=5470 From noreply at sourceforge.net Wed Nov 8 10:46:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 01:46:39 -0800 Subject: [ python-Bugs-1592533 ] Unfortunate naming of variable in heapq example Message-ID: Bugs item #1592533, was opened at 2006-11-08 10: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=1592533&group_id=5470 Please note that this 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 Private: No Submitted By: Martin Thorsen Ranang (ranang) Assigned to: Nobody/Anonymous (nobody) Summary: Unfortunate naming of variable in heapq example Initial Comment: In the current "Python Library Reference" documentation, in section "5.4 heapq -- Heap queue algorithm", an example goes: >>> sorted = [] >>> while heap: ... sorted.append(heappop(heap)) ... >>> print sorted [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] However, 'sorted' is the name of a built-in function. Of course, the example does not constitute an error, but it might be misleading to new users of the language. Consider: >>> sorted = [] >>> should_be_sorted = sorted([4, 3, 1, 2]) Traceback (most recent call last): File "", line 1, in ? TypeError: 'list' object is not callable >>> Hence, I suggest to rename the variable in the example to 'ordered'. Yours, Martin Thorsen Ranang ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1592533&group_id=5470 From noreply at sourceforge.net Wed Nov 8 11:04:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 02:04:46 -0800 Subject: [ python-Bugs-1592533 ] Unfortunate naming of variable in heapq example Message-ID: Bugs item #1592533, was opened at 2006-11-08 09:46 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1592533&group_id=5470 Please note that this 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 Private: No Submitted By: Martin Thorsen Ranang (ranang) >Assigned to: Georg Brandl (gbrandl) Summary: Unfortunate naming of variable in heapq example Initial Comment: In the current "Python Library Reference" documentation, in section "5.4 heapq -- Heap queue algorithm", an example goes: >>> sorted = [] >>> while heap: ... sorted.append(heappop(heap)) ... >>> print sorted [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] However, 'sorted' is the name of a built-in function. Of course, the example does not constitute an error, but it might be misleading to new users of the language. Consider: >>> sorted = [] >>> should_be_sorted = sorted([4, 3, 1, 2]) Traceback (most recent call last): File "", line 1, in ? TypeError: 'list' object is not callable >>> Hence, I suggest to rename the variable in the example to 'ordered'. Yours, Martin Thorsen Ranang ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-08 10:04 Message: Logged In: YES user_id=849994 Thanks! Fixed in rev. 52668, 52669 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1592533&group_id=5470 From noreply at sourceforge.net Wed Nov 8 14:23:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 05:23:37 -0800 Subject: [ python-Bugs-1592627 ] gettext has problems with .mo files that use non-ASCII chars Message-ID: Bugs item #1592627, was opened at 2006-11-08 13: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=1592627&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Russell Phillips (avantman42) Assigned to: Nobody/Anonymous (nobody) Summary: gettext has problems with .mo files that use non-ASCII chars Initial Comment: Hi, I'm trying to use gettext to internationalise my project [1], but I'm getting the following error message with some translations: "Traceback (most recent call last): file PanicButton.py line 36 in ? file Gettext.pyc line 177 in _init_ file Gettext.pyc line 274 in _parse struct.error : unpack str size does not match format" The snippet of code that loads the .mo file is below (full file is at [2]): # Code to find & install l10n file import gettext, os, locale, glob loc = locale.getdefaultlocale () sLocale = loc [0] #Use translation file with same name as locale if it exists if (os.path.exists (os.path.join ('locale', sLocale + '.mo'))): sLang = os.path.join ('locale', sLocale + '.mo') else: #find a .mo file that matches the first part (first three characters) of the locale sMoFiles = glob.glob (os.path.join ('locale', sLocale [:3] + '*.mo')) if (len (sMoFiles) > 0): sLang = sMoFiles [0] else: #Could not find exact or partial match for locale - use default translation file (British English) sLang = os.path.join ('locale', 'en_GB.mo') lan = gettext.GNUTranslations (open (sLang)) lan.install () # End of code to find & install l10n file The problem only seems to appear when the translated file uses non-ASCII characters. Full sourcecode is available via the SF.net project page [1], if required. The .po and .mo files are in the locale directory [3]. The only .mo file that does not have problems is en_GB.mo Russ [1] http://sourceforge.net/projects/panicbutton [2] http://panicbutton.cvs.sourceforge.net/panicbutton/panicbutton/PanicButton.py?view=log [3] http://panicbutton.cvs.sourceforge.net/panicbutton/panicbutton/locale/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1592627&group_id=5470 From noreply at sourceforge.net Wed Nov 8 17:45:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 08:45:36 -0800 Subject: [ python-Bugs-1590891 ] random.randrange don't return correct value for big number Message-ID: Bugs item #1590891, was opened at 2006-11-05 08:54 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590891&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: MATSUI Tetsushi (mft) Assigned to: Raymond Hettinger (rhettinger) Summary: random.randrange don't return correct value for big number Initial Comment: Python 2.4.3 (#1, Oct 3 2006, 00:36:06) [GCC 4.1.1 (Gentoo 4.1.1-r1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import random >>> random.randrange(1000000000000, -100000000000000000000, -200) 267471051174796896L Obviously, the result is not in the specified range; 1000000000000 < 267471051174796896, -100000000000000000000 < 267471051174796896 and (267471051174796896 - 1000000000000) % (-200) != 0. I'm using 2.3.5 and 2.4.3, and their behaviors are identical. I haven't checked about 2.5. ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-11-08 08:45 Message: Logged In: YES user_id=341410 2.5 has the same behavior. One workaround (until it gets fixed) is to do the following... def myrandrange(start, stop, step): return start + random.randrange((stop-start)//step)*step random.randrange should change to do some variant of the above, given sane start, stop, step arguments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590891&group_id=5470 From noreply at sourceforge.net Wed Nov 8 17:56:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 08:56:19 -0800 Subject: [ python-Bugs-1591319 ] replace groups doesn't work in this special case Message-ID: Bugs item #1591319, was opened at 2006-11-06 12:49 Message generated for change (Comment added) made by tomek74 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591319&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.4 >Status: Open >Resolution: None Priority: 5 Private: No Submitted By: Thomas K. (tomek74) Assigned to: Gustavo Niemeyer (niemeyer) Summary: replace groups doesn't work in this special case Initial Comment: If you have a regular expression like this: ([0-9])([a-z])? matching this string: 1 1a and replacing with this: yx you get what expected: yx yx BUT: If you replace with this: \1\2 you get nothing replaced, because the group \2 doesn't exist for the pattern "1". But it does exist for the pattern "1a"! We have multiple possibilities here: 1.) The string "1" gives no result, because \2 doesn't exist. The string "1a" gives a result, so the output should be: 1a 2.) The sring "1" gives a result, because \2 is handled like an empty string. The string "1a" gives a result, so the output should be: 1 1a I think the case that the sring "1" has no results, but effects the string "1a" wich would normaly have a result, is bad. What are your thoughts on it? Test code: import re # common variables rawstr = r"""([0-9])([a-z])?""" embedded_rawstr = r"""([0-9])([a-z])?""" matchstr = """1 1a""" # method 1: using a compile object compile_obj = re.compile(rawstr) match_obj = compile_obj.search(matchstr) # method 2: using search function (w/ external flags) match_obj = re.search(rawstr, matchstr) # method 3: using search function (w/ embedded flags) match_obj = re.search(embedded_rawstr, matchstr) # Retrieve group(s) from match_obj all_groups = match_obj.groups() # Retrieve group(s) by index group_1 = match_obj.group(1) group_2 = match_obj.group(2) # Replace string newstr = compile_obj.subn('\1\2', 0) ---------------------------------------------------------------------- >Comment By: Thomas K. (tomek74) Date: 2006-11-08 17:56 Message: Logged In: YES user_id=22427 I have tried it again with my original regexp and the searchstring. In this case I have to put the ??? after ?)?. -> RegEx: ([1-9][a-z][a-z][0-9])([ \-\r\n\t]*([0-9])(([0-9])(([0-9])([ \-\r\n\t]*([0-9])(([a-z])(([a-z])(([0-9])(([0-9])([ \-\r\n\t]*([0-9])(([a-z])(([a-z])(([0-9]))?)?)?)?)?)?)?)?)?)?)?)? IGNORECASE is switched on. -> ReplaceString: \1\3\5\7\9\11\13\15\17\19\21\23\25 -> Searchstring 1): 6ES5894-0MA63-0UG5 Result: 6ES58940MA630UG5 -> Searchstring 2): 6ES5894-0MA03; 6ES5864-0MA03; 6ES5894-0MA63-0UG5; 6ES58860MA03 Result: NO Result! -> The problem is that I get no results with searchstring 2. Thomas ---------------------------------------------------------------------- Comment By: Thomas K. (tomek74) Date: 2006-11-07 11:36 Message: Logged In: YES user_id=22427 I verified your code. It works for me, too. Sorry. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-11-06 13:17 Message: Logged In: YES user_id=7887 Hello Thomas, I don't understand exactly what you mean here. This doesn't work: >>> re.compile("([0-9])([a-z])?").subn(r"<\1\2>", "1 1a") Traceback (most recent call last): ... sre_constants.error: unmatched group And this works fine: >>> re.compile("([0-9])([a-z]?)").subn(r"<\1\2>", "1 1a") ('<1> <1a>', 2) The example code you provided doesn't run here, because 'subn()' is being provided bad data (check http://docs.python.org/lib/node46.html for docs). It's also being passed '\1\2', which is really '\x01\x02', and won't do what you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591319&group_id=5470 From noreply at sourceforge.net Wed Nov 8 21:23:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 12:23:20 -0800 Subject: [ python-Feature Requests-1592899 ] "".translate() docs should mention string.maketrans() Message-ID: Feature Requests item #1592899, was opened at 2006-11-08 22:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1592899&group_id=5470 Please note that this 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 Private: No Submitted By: Ori Avtalion (salty-horse) Assigned to: Nobody/Anonymous (nobody) Summary: "".translate() docs should mention string.maketrans() Initial Comment: The translate() documentation at http://docs.python.org/lib/string-methods.html#l2h-268 should mention the string.maketrans helper function. maketrans also mentions "regex.compile" - that should probably be "re.compile" (although it's less readable). re.compile should mention maketrans as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1592899&group_id=5470 From noreply at sourceforge.net Wed Nov 8 22:45:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 13:45:48 -0800 Subject: [ python-Bugs-1592627 ] gettext has problems with .mo files that use non-ASCII chars Message-ID: Bugs item #1592627, was opened at 2006-11-08 14:23 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1592627&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None >Status: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Russell Phillips (avantman42) Assigned to: Nobody/Anonymous (nobody) Summary: gettext has problems with .mo files that use non-ASCII chars Initial Comment: Hi, I'm trying to use gettext to internationalise my project [1], but I'm getting the following error message with some translations: "Traceback (most recent call last): file PanicButton.py line 36 in ? file Gettext.pyc line 177 in _init_ file Gettext.pyc line 274 in _parse struct.error : unpack str size does not match format" The snippet of code that loads the .mo file is below (full file is at [2]): # Code to find & install l10n file import gettext, os, locale, glob loc = locale.getdefaultlocale () sLocale = loc [0] #Use translation file with same name as locale if it exists if (os.path.exists (os.path.join ('locale', sLocale + '.mo'))): sLang = os.path.join ('locale', sLocale + '.mo') else: #find a .mo file that matches the first part (first three characters) of the locale sMoFiles = glob.glob (os.path.join ('locale', sLocale [:3] + '*.mo')) if (len (sMoFiles) > 0): sLang = sMoFiles [0] else: #Could not find exact or partial match for locale - use default translation file (British English) sLang = os.path.join ('locale', 'en_GB.mo') lan = gettext.GNUTranslations (open (sLang)) lan.install () # End of code to find & install l10n file The problem only seems to appear when the translated file uses non-ASCII characters. Full sourcecode is available via the SF.net project page [1], if required. The .po and .mo files are in the locale directory [3]. The only .mo file that does not have problems is en_GB.mo Russ [1] http://sourceforge.net/projects/panicbutton [2] http://panicbutton.cvs.sourceforge.net/panicbutton/panicbutton/PanicButton.py?view=log [3] http://panicbutton.cvs.sourceforge.net/panicbutton/panicbutton/locale/ ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-08 22:45 Message: Logged In: YES user_id=21627 I can't reproduce the problem. If I understand your description correctly, then this line should fail py> gettext.GNUTranslations(open("de_DE.mo")) However, it doesn't fail for me, neither with Python 2.4.4 or 2.5. Are you, by any chance, using Microsoft Windows? If so, you should open the file in binary mode (you should actually do so on all systems; .mo files are binary): gettext.GNUTranslations (open (sLang, 'rb')) Also, I'm puzzled by your traceback. It says file Gettext.pyc line 177 in _init_ file Gettext.pyc line 274 in _parse However, Python does not include a file named Gettext.py[c], only gettext.py (lower case 'g'). Where did you get Gettext.pyc from? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1592627&group_id=5470 From noreply at sourceforge.net Wed Nov 8 22:51:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 13:51:55 -0800 Subject: [ python-Bugs-1591122 ] problem building python in vs8express Message-ID: Bugs item #1591122, was opened at 2006-11-06 05:31 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&group_id=5470 Please note that this 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 Private: No Submitted By: Thomas Southern (thomashsouthern) Assigned to: Nobody/Anonymous (nobody) Summary: problem building python in vs8express Initial Comment: When I tried to build pythoncore in vc++8 express, it worked without a hitch until the link stage when i got an unresolved external _init_types. Python compiles just fine and pythonw compiles up to the link where it comes accross the same error. If I am suppose to contact someone else about my issue please sent me in the wright direction. my email is thomashsouthern at yahoo.com ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-08 22:51 Message: Logged In: YES user_id=21627 If you want to check out the sources, you should familiarize yourself with subversion. With a command line client, the checkout line would be svn co http://svn.python.org/projects/python/trunk or svn co http://svn.python.org/projects/python/branches/release25-maint If you want to use TortoiseSVN, just use the URL in the checkout dialog. This problem is fixed both in the trunk and the 2.5 branch, so you may just wait for 2.5.1 being released (which will happen some time next year). Closing as fixed. ---------------------------------------------------------------------- Comment By: Thomas Southern (thomashsouthern) Date: 2006-11-08 02:14 Message: Logged In: YES user_id=1638546 thank you for your responses. after I answered your first question i went in search of the svn head for this project. I started at www.python.org and went to the developement area. I found svn trunk where the files for python 2.6 were located. I appolgize if I appear ignorant but I have never been interested in an open source project enough to want to compile from scratch and maybe even try and see what I could contribute. I don't know if I found the right area. where I did find. I would need to download each file individually. also, the "solution items" with "getbuildinfo.c" was not recognized by the vc++ express compiler. My question is this, am I looking in the correct location for the files I am looking for to build the source myself. also if this brings me out of the preview of the purpose of this thread please direct me to the proper location to continue to ask questions I might have as I try to understand my way around this project. thank you for your patients and help. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-07 16:41 Message: Logged In: YES user_id=849994 So could you please retry with the SVN HEAD? ---------------------------------------------------------------------- Comment By: Thomas Southern (thomashsouthern) Date: 2006-11-07 01:59 Message: Logged In: YES user_id=1638546 I am using python 2.5 ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-06 08:46 Message: Logged In: YES user_id=849994 Which version of the sources are you using? I think this is fixed in the SVN HEAD. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591122&group_id=5470 From noreply at sourceforge.net Wed Nov 8 23:22:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 14:22:30 -0800 Subject: [ python-Bugs-1590891 ] random.randrange don't return correct value for big number Message-ID: Bugs item #1590891, was opened at 2006-11-05 16:54 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590891&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: MATSUI Tetsushi (mft) Assigned to: Raymond Hettinger (rhettinger) Summary: random.randrange don't return correct value for big number Initial Comment: Python 2.4.3 (#1, Oct 3 2006, 00:36:06) [GCC 4.1.1 (Gentoo 4.1.1-r1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import random >>> random.randrange(1000000000000, -100000000000000000000, -200) 267471051174796896L Obviously, the result is not in the specified range; 1000000000000 < 267471051174796896, -100000000000000000000 < 267471051174796896 and (267471051174796896 - 1000000000000) % (-200) != 0. I'm using 2.3.5 and 2.4.3, and their behaviors are identical. I haven't checked about 2.5. ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-11-08 22:22 Message: Logged In: YES user_id=4771 Oups. If the interval is very large, the step is ignored. Patch attached... ---------------------------------------------------------------------- Comment By: Josiah Carlson (josiahcarlson) Date: 2006-11-08 16:45 Message: Logged In: YES user_id=341410 2.5 has the same behavior. One workaround (until it gets fixed) is to do the following... def myrandrange(start, stop, step): return start + random.randrange((stop-start)//step)*step random.randrange should change to do some variant of the above, given sane start, stop, step arguments. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590891&group_id=5470 From noreply at sourceforge.net Thu Nov 9 00:38:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 15:38:20 -0800 Subject: [ python-Bugs-1572320 ] parser stack overflow Message-ID: Bugs item #1572320, was opened at 2006-10-06 14:37 Message generated for change (Comment added) made by jackdied You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572320&group_id=5470 Please note that this 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 Private: No Submitted By: j?rgen urner (cereb_00) Assigned to: Nobody/Anonymous (nobody) Summary: parser stack overflow Initial Comment: Executing this raw (malformed) tuple raises: s_push: parser stack overflow MemoryError instead of SyntaxError. Sorry for not tracking it down more, but the tuple was actually much longer, so I did at least a bit of that. Removing the last member raises SyntaxError as expected. ( ("indigo", "#4B0082)", ("gold", "#FFD700)", ("firebrick", "#B22222)", ("indianred", "#CD5C5C)", ("yellow", "#FFFF00)", ("darkolivegreen", "#556B2F)", ("darkseagreen", "#8FBC8F)", ("mediumvioletred", "#C71585)", ("mediumorchid", "#BA55D3)", ("chartreuse", "#7FFF00)", ("mediumslateblue", "#7B68EE)", ("black", "#000000)", ("springgreen", "#00FF7F)", ("crimson", "#DC143C)", ("lightsalmon", "#FFA07A)", ("brown", "#A52A2A)", ("turquoise", "#40E0D0)", ("olivedrab", "#6B8E23)", ("silver", "#C0C0C0)", ("skyblue", "#87CEEB)", ("gray", "#808080)", ("darkturquoise", "#00CED1)", ("goldenrod", "#DAA520)", ("darkgreen", "#006400)", ("darkviolet", "#9400D3)", ("darkgray", "#A9A9A9)", ("lime", "#00FF00)", ("lightpink", "#FFB6C1)", ("teal", "#008080)", ("darkmagenta", "#8B008B)", ("lightgoldenrodyellow", "#FAFAD2)", ("lavender", "#E6E6FA)", ) ---------------------------------------------------------------------- Comment By: Jack Diederich (jackdied) Date: 2006-11-08 18:38 Message: Logged In: YES user_id=591932 Here is a simpler testcase (((((((((((((((((((((((((((((((((() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1572320&group_id=5470 From noreply at sourceforge.net Thu Nov 9 00:48:54 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 15:48:54 -0800 Subject: [ python-Bugs-1593035 ] readline problem on ia64-unknown-linux-gnu Message-ID: Bugs item #1593035, was opened at 2006-11-08 18:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593035&group_id=5470 Please note that this message 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 Private: No Submitted By: Kate Minola (kate01123) Assigned to: Nobody/Anonymous (nobody) Summary: readline problem on ia64-unknown-linux-gnu Initial Comment: On my ia64-unknown-linux-gnu machine, running python-2.5, if I import the following code (foo.py) and then try to do file name completion, I get a segmentation fault. Specifically, if after importing foo.py, if I type "im" and then [tab], I get a segmentation fault. I built python-2.5 from source using the default values. (All I did was "configure", then "make".) This does NOT happen under python-2.4.4. ----- foo.py ------ try: import rlcompleter,readline except ImportError: print '*** No readline support ***' pass else: readline.set_history_length(1000) # parse and bind all these: rlcmds = ['tab: complete', r'"\M-p": history-search-backward', r'"\M-n": history-search-forward', r'"\C-p": history-search-backward', r'"\C-n": history-search-forward', r'"\e[A": history-search-backward', r'"\e[B": history-search-forward', 'set show-all-if-ambiguous on', ] map(readline.parse_and_bind,rlcmds) ----------------------- %uname -a Linux lepidus 2.4.21-sgi302r24 #1 SMP Fri Oct 22 22:43:12 PDT 2004 ia64 ia64 ia64 GNU/Linux % % ./python --version Python 2.5 % % ./python Python 2.5 (r25:51908, Nov 8 2006, 15:40:13) [GCC 4.1.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import foo >>> impSegmentation fault (core dumped) % % gdb ./python GNU gdb Red Hat Linux (6.0post-0.20040223.20rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "ia64-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) r Starting program: /home/kate/sage/william/Python-2.5/python [Thread debugging using libthread_db enabled] [New Thread 2305843009213881680 (LWP 23166)] Python 2.5 (r25:51908, Nov 8 2006, 15:40:13) [GCC 4.1.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import foo >>> im Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 2305843009213881680 (LWP 23166)] 0x200000000264ae90 in rl_complete_internal () from /usr/lib/libreadline.so.4 (gdb) bt #0 0x200000000264ae90 in rl_complete_internal () from /usr/lib/libreadline.so.4 #1 0x2000000002646d90 in rl_complete () from /usr/lib/libreadline.so.4 #2 0x200000000263bc40 in _rl_dispatch_subseq () from /usr/lib/libreadline.so.4 #3 0x200000000263b780 in _rl_dispatch () from /usr/lib/libreadline.so.4 #4 0x200000000263af90 in readline_internal_char () from /usr/lib/libreadline.so.4 #5 0x0000000000000000 in ?? () (gdb) Kate Minola University of Maryland, College Park ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593035&group_id=5470 From noreply at sourceforge.net Thu Nov 9 07:58:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 22:58:55 -0800 Subject: [ python-Feature Requests-449227 ] rlcompleter add " (" to callables feature Message-ID: Feature Requests item #449227, was opened at 2001-08-08 18:04 Message generated for change (Comment added) made by rnd0110 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449227&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roman Suzi (rnd0110) Assigned to: Nobody/Anonymous (nobody) Summary: rlcompleter add "(" to callables feature Initial Comment: I use rlcompleter extensively in interactive Python mode. I think it could be cool if callable objects were added "(" when completed. This way it will be much faster to program, without looking-up __doc__. For example: >>> f.fil<TAB> will give: >>> f.fileno(_ ("_" is to mark cursor position) and: >>> f.so<TAB> will (as before) give: >>> f.softspace _ ---------------------------------------------------------------------- >Comment By: Roman Suzi (rnd0110) Date: 2006-11-09 06:58 Message: Logged In: YES user_id=287815 Perhaps one needs to propose a patch. Otherwise it will not advance... ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-07-17 13:15 Message: Logged In: YES user_id=1188172 Any comments on this one? Sounds reasonable to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449227&group_id=5470 From noreply at sourceforge.net Thu Nov 9 08:01:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 23:01:04 -0800 Subject: [ python-Feature Requests-449227 ] rlcompleter add " (" to callables feature Message-ID: Feature Requests item #449227, was opened at 2001-08-08 18:04 Message generated for change (Comment added) made by rnd0110 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449227&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roman Suzi (rnd0110) Assigned to: Nobody/Anonymous (nobody) Summary: rlcompleter add "(" to callables feature Initial Comment: I use rlcompleter extensively in interactive Python mode. I think it could be cool if callable objects were added "(" when completed. This way it will be much faster to program, without looking-up __doc__. For example: >>> f.fil<TAB> will give: >>> f.fileno(_ ("_" is to mark cursor position) and: >>> f.so<TAB> will (as before) give: >>> f.softspace _ ---------------------------------------------------------------------- >Comment By: Roman Suzi (rnd0110) Date: 2006-11-09 07:01 Message: Logged In: YES user_id=287815 Wow! The patch is here! Why isn't is accepted into the distribution??? ---------------------------------------------------------------------- Comment By: Roman Suzi (rnd0110) Date: 2006-11-09 06:58 Message: Logged In: YES user_id=287815 Perhaps one needs to propose a patch. Otherwise it will not advance... ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-07-17 13:15 Message: Logged In: YES user_id=1188172 Any comments on this one? Sounds reasonable to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449227&group_id=5470 From noreply at sourceforge.net Thu Nov 9 08:57:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 08 Nov 2006 23:57:28 -0800 Subject: [ python-Feature Requests-449227 ] rlcompleter add " (" to callables feature Message-ID: Feature Requests item #449227, was opened at 2001-08-08 18:04 Message generated for change (Comment added) made by rnd0110 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449227&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Library >Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roman Suzi (rnd0110) Assigned to: Nobody/Anonymous (nobody) Summary: rlcompleter add "(" to callables feature Initial Comment: I use rlcompleter extensively in interactive Python mode. I think it could be cool if callable objects were added "(" when completed. This way it will be much faster to program, without looking-up __doc__. For example: >>> f.fil<TAB> will give: >>> f.fileno(_ ("_" is to mark cursor position) and: >>> f.so<TAB> will (as before) give: >>> f.softspace _ ---------------------------------------------------------------------- >Comment By: Roman Suzi (rnd0110) Date: 2006-11-09 07:57 Message: Logged In: YES user_id=287815 One more illustration: >>> f = open("myfile", "w") >>> f. f.__class__( f.__repr__( f.next( f.__delattr__( f.__setattr__( f.read( f.__doc__ f.__str__( f.readinto( f.__enter__( f.close( f.readline( f.__exit__( f.closed f.readlines( f.__getattribute__( f.encoding f.seek( f.__hash__( f.fileno( f.softspace f.__init__( f.flush( f.tell( f.__iter__( f.isatty( f.truncate( f.__new__( f.mode f.write( f.__reduce__( f.name f.writelines( f.__reduce_ex__( f.newlines f.xreadlines( >>> f. - nice to remember which attributes are methods and which aren't. ---------------------------------------------------------------------- Comment By: Roman Suzi (rnd0110) Date: 2006-11-09 07:01 Message: Logged In: YES user_id=287815 Wow! The patch is here! Why isn't is accepted into the distribution??? ---------------------------------------------------------------------- Comment By: Roman Suzi (rnd0110) Date: 2006-11-09 06:58 Message: Logged In: YES user_id=287815 Perhaps one needs to propose a patch. Otherwise it will not advance... ---------------------------------------------------------------------- Comment By: Georg Brandl (birkenfeld) Date: 2005-07-17 13:15 Message: Logged In: YES user_id=1188172 Any comments on this one? Sounds reasonable to me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=449227&group_id=5470 From noreply at sourceforge.net Thu Nov 9 11:59:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 02:59:16 -0800 Subject: [ python-Bugs-1592627 ] gettext has problems with .mo files that use non-ASCII chars Message-ID: Bugs item #1592627, was opened at 2006-11-08 13:23 Message generated for change (Comment added) made by avantman42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1592627&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Russell Phillips (avantman42) Assigned to: Nobody/Anonymous (nobody) Summary: gettext has problems with .mo files that use non-ASCII chars Initial Comment: Hi, I'm trying to use gettext to internationalise my project [1], but I'm getting the following error message with some translations: "Traceback (most recent call last): file PanicButton.py line 36 in ? file Gettext.pyc line 177 in _init_ file Gettext.pyc line 274 in _parse struct.error : unpack str size does not match format" The snippet of code that loads the .mo file is below (full file is at [2]): # Code to find & install l10n file import gettext, os, locale, glob loc = locale.getdefaultlocale () sLocale = loc [0] #Use translation file with same name as locale if it exists if (os.path.exists (os.path.join ('locale', sLocale + '.mo'))): sLang = os.path.join ('locale', sLocale + '.mo') else: #find a .mo file that matches the first part (first three characters) of the locale sMoFiles = glob.glob (os.path.join ('locale', sLocale [:3] + '*.mo')) if (len (sMoFiles) > 0): sLang = sMoFiles [0] else: #Could not find exact or partial match for locale - use default translation file (British English) sLang = os.path.join ('locale', 'en_GB.mo') lan = gettext.GNUTranslations (open (sLang)) lan.install () # End of code to find & install l10n file The problem only seems to appear when the translated file uses non-ASCII characters. Full sourcecode is available via the SF.net project page [1], if required. The .po and .mo files are in the locale directory [3]. The only .mo file that does not have problems is en_GB.mo Russ [1] http://sourceforge.net/projects/panicbutton [2] http://panicbutton.cvs.sourceforge.net/panicbutton/panicbutton/PanicButton.py?view=log [3] http://panicbutton.cvs.sourceforge.net/panicbutton/panicbutton/locale/ ---------------------------------------------------------------------- >Comment By: Russell Phillips (avantman42) Date: 2006-11-09 10:59 Message: Logged In: YES user_id=316750 Got it working. Thank you so much! I am using Windows, and I'd tried open (sLang, 'rb') and it didn't make a difference, but that was when I was using Python 2.4. I'm not sure why it works now and didn't then, but I'm just happy to have it working. The Gettext.pyc file came with the Windows Python distribution. Russ ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-08 21:45 Message: Logged In: YES user_id=21627 I can't reproduce the problem. If I understand your description correctly, then this line should fail py> gettext.GNUTranslations(open("de_DE.mo")) However, it doesn't fail for me, neither with Python 2.4.4 or 2.5. Are you, by any chance, using Microsoft Windows? If so, you should open the file in binary mode (you should actually do so on all systems; .mo files are binary): gettext.GNUTranslations (open (sLang, 'rb')) Also, I'm puzzled by your traceback. It says file Gettext.pyc line 177 in _init_ file Gettext.pyc line 274 in _parse However, Python does not include a file named Gettext.py[c], only gettext.py (lower case 'g'). Where did you get Gettext.pyc from? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1592627&group_id=5470 From noreply at sourceforge.net Thu Nov 9 13:49:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 04:49:41 -0800 Subject: [ python-Bugs-1593384 ] No IDLE in Windows Message-ID: Bugs item #1593384, was opened at 2006-11-09 15: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=1593384&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: A_V_I (a_v_i) Assigned to: Nobody/Anonymous (nobody) Summary: No IDLE in Windows Initial Comment: I have installed Python 2.5 on WinXP using python-25.msi with all features included and all default direcories , etc. When I tried to use IDLE I had got the following results: - shortcut in Start -> ... does not do anything - no IDLE in Python25\Tools How can I get IDLE for usage? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 From noreply at sourceforge.net Thu Nov 9 14:22:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 05:22:05 -0800 Subject: [ python-Bugs-1593407 ] No IDLE in Windows Message-ID: Bugs item #1593407, was opened at 2006-11-09 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=1593407&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: A_V_I (a_v_i) Assigned to: Nobody/Anonymous (nobody) Summary: No IDLE in Windows Initial Comment: I have installed Python 2.5 on WinXP using python-25.msi with all features included and all default direcories , etc. When I tried to use IDLE I had got the following results: - shortcut in Start -> ... does not do anything - no IDLE in Python25\Tools How can I get IDLE for usage? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593407&group_id=5470 From noreply at sourceforge.net Thu Nov 9 14:34:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 05:34:11 -0800 Subject: [ python-Bugs-1569790 ] mailbox.Maildir.get_folder() loses factory information Message-ID: Bugs item #1569790, was opened at 2006-10-03 04:16 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569790&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Matthias Klose (doko) >Assigned to: A.M. Kuchling (akuchling) Summary: mailbox.Maildir.get_folder() loses factory information Initial Comment: [forwarded from http://bugs.debian.org/384512] the factory defines what class the mails have that are returned. So for two nested folders a and a.b, the following code will return messages with two different classes: # factory = None to get mailbox.MaildirMessage objects md = mailbox.Maildir("a", factory=None) print md["somemessage"].__class__ # will print mailbox.MaildirMessage md2 = md.get_folder("b") print md2["someothermessage"].__class__ # will print rfc822.Message i.e. the factory= parameter passed to the outer Maildir class upon creation is not passed on to the subfolder creation in get_folder() ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-11-09 08:34 Message: Logged In: YES user_id=11375 Committed to trunk in rev. 52690 and to 25-maint in rev. 52691. Thanks for the bug report! The MH class has the same bug, so I fixed that too. I've also attached the patch. If you wish you can incorporate the fix in Debian's patchset, or wait for Python 2.5.1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569790&group_id=5470 From noreply at sourceforge.net Thu Nov 9 14:34:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 05:34:46 -0800 Subject: [ python-Bugs-1593407 ] No IDLE in Windows Message-ID: Bugs item #1593407, was opened at 2006-11-09 08:22 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593407&group_id=5470 Please note that this 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: None >Status: Deleted >Resolution: Duplicate Priority: 5 Private: No Submitted By: A_V_I (a_v_i) Assigned to: Nobody/Anonymous (nobody) Summary: No IDLE in Windows Initial Comment: I have installed Python 2.5 on WinXP using python-25.msi with all features included and all default direcories , etc. When I tried to use IDLE I had got the following results: - shortcut in Start -> ... does not do anything - no IDLE in Python25\Tools How can I get IDLE for usage? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593407&group_id=5470 From noreply at sourceforge.net Thu Nov 9 15:04:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 06:04:13 -0800 Subject: [ python-Bugs-1593442 ] No IDLE in Windows Message-ID: Bugs item #1593442, was opened at 2006-11-09 17:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593442&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: A_V_I (a_v_i) Assigned to: Nobody/Anonymous (nobody) Summary: No IDLE in Windows Initial Comment: I have installed Python 2.5 on WinXP using python-25.msi with all features included and all default direcories , etc. When I tried to use IDLE I had got the following results: - shortcut in Start -> ... does not do anything - no IDLE in Python25\Tools How can I get IDLE for usage? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593442&group_id=5470 From noreply at sourceforge.net Thu Nov 9 15:55:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 06:55:35 -0800 Subject: [ python-Bugs-1566719 ] site-packages isn't created before install_egg_info Message-ID: Bugs item #1566719, was opened at 2006-09-27 21:34 Message generated for change (Comment added) made by jfunk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566719&group_id=5470 Please note that this 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 Private: No Submitted By: James Oakley (jfunk) Assigned to: Nobody/Anonymous (nobody) Summary: site-packages isn't created before install_egg_info Initial Comment: install_egg_info is called without creating the site-packages directory when only a script is specified. This can break RPM builds since the site-packages directory isn't present beforehand. Here's an setup.py that causes this problem:: from distutils.core import setup setup(name='dot2tex', version='1.0.1', description = 'A Graphviz to LaTeX converter', author = 'Kjell Magne Fauske', author_email = 'kjellmf at gmail.com', url = "http://www.fauskes.net/code/dot2tex/", download_url = "http://www.fauskes.net/code/dot2tex/download/", scripts=['dot2tex/dot2tex.py'] ) Here's the build output:: + python setup.py install --prefix=/usr --root=/var/tmp/dot2tex-buildroot --record=INSTALLED_FILES running install running build running build_scripts running install_scripts creating /var/tmp/dot2tex-buildroot creating /var/tmp/dot2tex-buildroot/usr creating /var/tmp/dot2tex-buildroot/usr/bin copying build/scripts-2.5/dot2tex.py -> /var/tmp/dot2tex-buildroot/usr/bin changing mode of /var/tmp/dot2tex-buildroot/usr/bin/dot2tex.py to 755 running install_egg_info Writing /var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info error: /var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info: No such file or directory ---------------------------------------------------------------------- >Comment By: James Oakley (jfunk) Date: 2006-11-09 10:55 Message: Logged In: YES user_id=8314 Hmm. For some reason SF didn't send your response, so I didn't see it. When building RPM packages, software is installed to a completely empty directory to avoid pollution to/from the host system. This means that the installation process should create any needed directories before trying to copy files to them. This is performed automatically when using GNU autotools, and in Python when installing scripts and modules. However, this is not performed when installing egg-info files in 2.5. It's not a problem when the package includes modules, since the site-packages directory gets created when the modules are installed before the egg-info. If a package does not include modules, the directory is not there and the egg-info installation fails. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-10-14 23: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: Martin v. L?wis (loewis) Date: 2006-09-28 00:26 Message: Logged In: YES user_id=21627 How can there not be a site-packages directory? It is created with the installation of Python itself, so it is always there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566719&group_id=5470 From noreply at sourceforge.net Thu Nov 9 16:47:33 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 07:47:33 -0800 Subject: [ python-Bugs-1593525 ] Modules/unicodedata.c contains C++-style comment Message-ID: Bugs item #1593525, was opened at 2006-11-09 10:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593525&group_id=5470 Please note that this 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 Private: No Submitted By: Mike Kent (mrmakent) Assigned to: Nobody/Anonymous (nobody) Summary: Modules/unicodedata.c contains C++-style comment Initial Comment: Line 78 of Python2.5 Modules/unicodedata.c is a C++-style comment, which causes the module to fail to compile under AIX 4.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593525&group_id=5470 From noreply at sourceforge.net Thu Nov 9 17:31:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 08:31:51 -0800 Subject: [ python-Bugs-1593525 ] Modules/unicodedata.c contains C++-style comment Message-ID: Bugs item #1593525, was opened at 2006-11-09 16:47 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593525&group_id=5470 Please note that this 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 Private: No Submitted By: Mike Kent (mrmakent) Assigned to: Nobody/Anonymous (nobody) Summary: Modules/unicodedata.c contains C++-style comment Initial Comment: Line 78 of Python2.5 Modules/unicodedata.c is a C++-style comment, which causes the module to fail to compile under AIX 4.2. ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-11-09 17:31 Message: Logged In: YES user_id=89016 Fixes in r52695 (trunk) and r52696 (release25-maint). Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593525&group_id=5470 From noreply at sourceforge.net Thu Nov 9 18:48:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 09:48:48 -0800 Subject: [ python-Bugs-1593634 ] No IDLE in Windows Message-ID: Bugs item #1593634, was opened at 2006-11-09 20: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=1593634&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: A_V_I (a_v_i) Assigned to: Nobody/Anonymous (nobody) Summary: No IDLE in Windows Initial Comment: I have installed Python 2.5 on WinXP using python-25.msi with all features included and all default direcories , etc. When I tried to use IDLE I had got the following results: - shortcut in Start -> ... does not do anything - no IDLE in Python25\Tools How can I get IDLE for usage? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593634&group_id=5470 From noreply at sourceforge.net Thu Nov 9 19:14:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 10:14:41 -0800 Subject: [ python-Bugs-1593442 ] No IDLE in Windows Message-ID: Bugs item #1593442, was opened at 2006-11-09 14:04 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593442&group_id=5470 Please note that this 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: None >Status: Deleted >Resolution: Duplicate Priority: 5 Private: No Submitted By: A_V_I (a_v_i) Assigned to: Nobody/Anonymous (nobody) Summary: No IDLE in Windows Initial Comment: I have installed Python 2.5 on WinXP using python-25.msi with all features included and all default direcories , etc. When I tried to use IDLE I had got the following results: - shortcut in Start -> ... does not do anything - no IDLE in Python25\Tools How can I get IDLE for usage? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593442&group_id=5470 From noreply at sourceforge.net Thu Nov 9 19:14:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 10:14:50 -0800 Subject: [ python-Bugs-1593634 ] No IDLE in Windows Message-ID: Bugs item #1593634, was opened at 2006-11-09 17:48 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593634&group_id=5470 Please note that this 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: None >Status: Deleted >Resolution: Duplicate Priority: 5 Private: No Submitted By: A_V_I (a_v_i) Assigned to: Nobody/Anonymous (nobody) Summary: No IDLE in Windows Initial Comment: I have installed Python 2.5 on WinXP using python-25.msi with all features included and all default direcories , etc. When I tried to use IDLE I had got the following results: - shortcut in Start -> ... does not do anything - no IDLE in Python25\Tools How can I get IDLE for usage? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593634&group_id=5470 From noreply at sourceforge.net Thu Nov 9 20:12:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 11:12:57 -0800 Subject: [ python-Bugs-1566719 ] site-packages isn't created before install_egg_info Message-ID: Bugs item #1566719, was opened at 2006-09-28 02:34 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566719&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.5 >Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Oakley (jfunk) Assigned to: Nobody/Anonymous (nobody) Summary: site-packages isn't created before install_egg_info Initial Comment: install_egg_info is called without creating the site-packages directory when only a script is specified. This can break RPM builds since the site-packages directory isn't present beforehand. Here's an setup.py that causes this problem:: from distutils.core import setup setup(name='dot2tex', version='1.0.1', description = 'A Graphviz to LaTeX converter', author = 'Kjell Magne Fauske', author_email = 'kjellmf at gmail.com', url = "http://www.fauskes.net/code/dot2tex/", download_url = "http://www.fauskes.net/code/dot2tex/download/", scripts=['dot2tex/dot2tex.py'] ) Here's the build output:: + python setup.py install --prefix=/usr --root=/var/tmp/dot2tex-buildroot --record=INSTALLED_FILES running install running build running build_scripts running install_scripts creating /var/tmp/dot2tex-buildroot creating /var/tmp/dot2tex-buildroot/usr creating /var/tmp/dot2tex-buildroot/usr/bin copying build/scripts-2.5/dot2tex.py -> /var/tmp/dot2tex-buildroot/usr/bin changing mode of /var/tmp/dot2tex-buildroot/usr/bin/dot2tex.py to 755 running install_egg_info Writing /var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info error: /var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info: No such file or directory ---------------------------------------------------------------------- Comment By: James Oakley (jfunk) Date: 2006-11-09 15:55 Message: Logged In: YES user_id=8314 Hmm. For some reason SF didn't send your response, so I didn't see it. When building RPM packages, software is installed to a completely empty directory to avoid pollution to/from the host system. This means that the installation process should create any needed directories before trying to copy files to them. This is performed automatically when using GNU autotools, and in Python when installing scripts and modules. However, this is not performed when installing egg-info files in 2.5. It's not a problem when the package includes modules, since the site-packages directory gets created when the modules are installed before the egg-info. If a package does not include modules, the directory is not there and the egg-info installation fails. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-10-15 04: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: Martin v. L?wis (loewis) Date: 2006-09-28 05:26 Message: Logged In: YES user_id=21627 How can there not be a site-packages directory? It is created with the installation of Python itself, so it is always there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566719&group_id=5470 From noreply at sourceforge.net Thu Nov 9 20:14:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 11:14:22 -0800 Subject: [ python-Bugs-1566719 ] site-packages isn't created before install_egg_info Message-ID: Bugs item #1566719, was opened at 2006-09-28 02:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566719&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Distutils Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: James Oakley (jfunk) >Assigned to: Phillip J. Eby (pje) Summary: site-packages isn't created before install_egg_info Initial Comment: install_egg_info is called without creating the site-packages directory when only a script is specified. This can break RPM builds since the site-packages directory isn't present beforehand. Here's an setup.py that causes this problem:: from distutils.core import setup setup(name='dot2tex', version='1.0.1', description = 'A Graphviz to LaTeX converter', author = 'Kjell Magne Fauske', author_email = 'kjellmf at gmail.com', url = "http://www.fauskes.net/code/dot2tex/", download_url = "http://www.fauskes.net/code/dot2tex/download/", scripts=['dot2tex/dot2tex.py'] ) Here's the build output:: + python setup.py install --prefix=/usr --root=/var/tmp/dot2tex-buildroot --record=INSTALLED_FILES running install running build running build_scripts running install_scripts creating /var/tmp/dot2tex-buildroot creating /var/tmp/dot2tex-buildroot/usr creating /var/tmp/dot2tex-buildroot/usr/bin copying build/scripts-2.5/dot2tex.py -> /var/tmp/dot2tex-buildroot/usr/bin changing mode of /var/tmp/dot2tex-buildroot/usr/bin/dot2tex.py to 755 running install_egg_info Writing /var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info error: /var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info: No such file or directory ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-09 20:14 Message: Logged In: YES user_id=21627 Phillip, can you take a look? If not, please unassign. ---------------------------------------------------------------------- Comment By: James Oakley (jfunk) Date: 2006-11-09 15:55 Message: Logged In: YES user_id=8314 Hmm. For some reason SF didn't send your response, so I didn't see it. When building RPM packages, software is installed to a completely empty directory to avoid pollution to/from the host system. This means that the installation process should create any needed directories before trying to copy files to them. This is performed automatically when using GNU autotools, and in Python when installing scripts and modules. However, this is not performed when installing egg-info files in 2.5. It's not a problem when the package includes modules, since the site-packages directory gets created when the modules are installed before the egg-info. If a package does not include modules, the directory is not there and the egg-info installation fails. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-10-15 04: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: Martin v. L?wis (loewis) Date: 2006-09-28 05:26 Message: Logged In: YES user_id=21627 How can there not be a site-packages directory? It is created with the installation of Python itself, so it is always there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566719&group_id=5470 From noreply at sourceforge.net Thu Nov 9 20:35:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 11:35:10 -0800 Subject: [ python-Bugs-1593384 ] No IDLE in Windows Message-ID: Bugs item #1593384, was opened at 2006-11-09 13:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: A_V_I (a_v_i) Assigned to: Nobody/Anonymous (nobody) Summary: No IDLE in Windows Initial Comment: I have installed Python 2.5 on WinXP using python-25.msi with all features included and all default direcories , etc. When I tried to use IDLE I had got the following results: - shortcut in Start -> ... does not do anything - no IDLE in Python25\Tools How can I get IDLE for usage? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-09 20:35 Message: Logged In: YES user_id=21627 Can you please report the properties of the IDLE shortcut? (right-button on the start menu item, properties) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 From noreply at sourceforge.net Thu Nov 9 22:04:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 13:04:07 -0800 Subject: [ python-Bugs-1593751 ] poor urllib error handling Message-ID: Bugs item #1593751, was opened at 2006-11-09 16: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=1593751&group_id=5470 Please note that this 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 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Nobody/Anonymous (nobody) Summary: poor urllib error handling Initial Comment: I set up a simple server that returns an empty response. >>> from socket import * >>> s = socket() >>> s.bind(("", 9999)) >>> while 1: x, c = s.accept(); print c; x.recv(1000); x.close() ... Pointing urllib at this gives a traceback: Python 2.6a0 (trunk:52099M, Oct 3 2006, 09:59:17) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import urllib >>> urllib.urlopen('http://localhost:9999/') Traceback (most recent call last): File "", line 1, in File "/home/guido/p/Lib/urllib.py", line 82, in urlopen return opener.open(url) File "/home/guido/p/Lib/urllib.py", line 190, in open return getattr(self, name)(url) File "/home/guido/p/Lib/urllib.py", line 334, in open_http return self.http_error(url, fp, errcode, errmsg, headers) File "/home/guido/p/Lib/urllib.py", line 351, in http_error return self.http_error_default(url, fp, errcode, errmsg, headers) File "/home/guido/p/Lib/urllib.py", line 608, in http_error_default return addinfourl(fp, headers, "http:" + url) File "/home/guido/p/Lib/urllib.py", line 951, in __init__ addbase.__init__(self, fp) File "/home/guido/p/Lib/urllib.py", line 898, in __init__ self.read = self.fp.read AttributeError: 'NoneType' object has no attribute 'read' >>> I can repeat this with 2.2.3 and 2.4.3 as well (don't have 2.3 around for testing). The direct cause of the problem is that h.getfile() on line 329 of urllib.py (in head of trunk) returns None. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593751&group_id=5470 From noreply at sourceforge.net Fri Nov 10 00:49:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 15:49:50 -0800 Subject: [ python-Bugs-1593829 ] small problem with description Message-ID: Bugs item #1593829, was opened at 2006-11-09 18: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=1593829&group_id=5470 Please note that this 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 Private: No Submitted By: Atlas (bauersj) Assigned to: Nobody/Anonymous (nobody) Summary: small problem with description Initial Comment: The ctypes documentation incorrectly indicates that pointers have a "value" attribute. I believe this should instead read a "contents" attribute. """ 14.14.2.7 Fundamental data types Subclasses of fundamental data types do not inherit this behaviour. So, if a foreign functions restype is a subclass of c_void_p, you will receive an instance of this subclass from the function call. Of course, you can get the value of the pointer by accessing the value attribute. """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593829&group_id=5470 From noreply at sourceforge.net Fri Nov 10 01:27:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 16:27:55 -0800 Subject: [ python-Bugs-1593829 ] small problem with description Message-ID: Bugs item #1593829, was opened at 2006-11-09 18:49 Message generated for change (Settings changed) made by bauersj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593829&group_id=5470 Please note that this 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: Deleted Resolution: None Priority: 5 Private: No Submitted By: Atlas (bauersj) Assigned to: Nobody/Anonymous (nobody) Summary: small problem with description Initial Comment: The ctypes documentation incorrectly indicates that pointers have a "value" attribute. I believe this should instead read a "contents" attribute. """ 14.14.2.7 Fundamental data types Subclasses of fundamental data types do not inherit this behaviour. So, if a foreign functions restype is a subclass of c_void_p, you will receive an instance of this subclass from the function call. Of course, you can get the value of the pointer by accessing the value attribute. """ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593829&group_id=5470 From noreply at sourceforge.net Fri Nov 10 01:36:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 09 Nov 2006 16:36:49 -0800 Subject: [ python-Bugs-1566719 ] site-packages isn't created before install_egg_info Message-ID: Bugs item #1566719, was opened at 2006-09-28 00:34 Message generated for change (Comment added) made by pje You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566719&group_id=5470 Please note that this 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: Fixed Priority: 5 Private: No Submitted By: James Oakley (jfunk) Assigned to: Phillip J. Eby (pje) Summary: site-packages isn't created before install_egg_info Initial Comment: install_egg_info is called without creating the site-packages directory when only a script is specified. This can break RPM builds since the site-packages directory isn't present beforehand. Here's an setup.py that causes this problem:: from distutils.core import setup setup(name='dot2tex', version='1.0.1', description = 'A Graphviz to LaTeX converter', author = 'Kjell Magne Fauske', author_email = 'kjellmf at gmail.com', url = "http://www.fauskes.net/code/dot2tex/", download_url = "http://www.fauskes.net/code/dot2tex/download/", scripts=['dot2tex/dot2tex.py'] ) Here's the build output:: + python setup.py install --prefix=/usr --root=/var/tmp/dot2tex-buildroot --record=INSTALLED_FILES running install running build running build_scripts running install_scripts creating /var/tmp/dot2tex-buildroot creating /var/tmp/dot2tex-buildroot/usr creating /var/tmp/dot2tex-buildroot/usr/bin copying build/scripts-2.5/dot2tex.py -> /var/tmp/dot2tex-buildroot/usr/bin changing mode of /var/tmp/dot2tex-buildroot/usr/bin/dot2tex.py to 755 running install_egg_info Writing /var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info error: /var/tmp/dot2tex-buildroot/usr/lib64/python2.5/site-packages/dot2tex-1.0.1-py2.5.egg-info: No such file or directory ---------------------------------------------------------------------- >Comment By: Phillip J. Eby (pje) Date: 2006-11-10 00:36 Message: Logged In: YES user_id=56214 I've checked in a fix as of revision 52716; presumably it should be backported to the 2.5 maintenance branch as well. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-09 19:14 Message: Logged In: YES user_id=21627 Phillip, can you take a look? If not, please unassign. ---------------------------------------------------------------------- Comment By: James Oakley (jfunk) Date: 2006-11-09 14:55 Message: Logged In: YES user_id=8314 Hmm. For some reason SF didn't send your response, so I didn't see it. When building RPM packages, software is installed to a completely empty directory to avoid pollution to/from the host system. This means that the installation process should create any needed directories before trying to copy files to them. This is performed automatically when using GNU autotools, and in Python when installing scripts and modules. However, this is not performed when installing egg-info files in 2.5. It's not a problem when the package includes modules, since the site-packages directory gets created when the modules are installed before the egg-info. If a package does not include modules, the directory is not there and the egg-info installation fails. ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-10-15 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: Martin v. L?wis (loewis) Date: 2006-09-28 03:26 Message: Logged In: YES user_id=21627 How can there not be a site-packages directory? It is created with the installation of Python itself, so it is always there. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1566719&group_id=5470 From noreply at sourceforge.net Fri Nov 10 15:39:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Nov 2006 06:39:51 -0800 Subject: [ python-Feature Requests-1542920 ] wsgi.org link in wsgiref Message-ID: Feature Requests item #1542920, was opened at 2006-08-18 19:17 Message generated for change (Comment added) made by akuchling 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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Ian Bicking (ianbicking) >Assigned to: A.M. Kuchling (akuchling) 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. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-11-10 09:39 Message: Logged In: YES user_id=11375 Done in rev. 52725 and 52726; the link will appear in the 2.5.1 docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1542920&group_id=5470 From noreply at sourceforge.net Fri Nov 10 15:52:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Nov 2006 06:52:19 -0800 Subject: [ python-Feature Requests-697985 ] Move gmtime function from calendar to time module Message-ID: Feature Requests item #697985, was opened at 2003-03-05 08:40 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=697985&group_id=5470 Please note that this 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: Wont Fix Priority: 5 Private: No Submitted By: Erland Lewin (erl) Assigned to: Nobody/Anonymous (nobody) Summary: Move gmtime function from calendar to time module Initial Comment: The gmtime function in the calendar module would be much more logical to have in the time module, since it manipulates tm tuples and unix timestamps, which the other functions in time do, but no other functions in calendar. Related to bug #697983 ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-11-10 09:52 Message: Logged In: YES user_id=11375 Closing per Tim's suggestion. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2003-06-28 02:36 Message: Logged In: YES user_id=80475 Erland, I propose that you close this one. The time and calendar API's have been around for a good while and changes would have a negative impact, even if they have some logic to it. The new datetime module for Py2.3 makes the time module obsolete; is organized logically; and should meet most of your needs. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-06-12 20:49 Message: Logged In: YES user_id=31435 Sorry, I don't have time to give to this. It's certainly not a bug report <wink>. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-29 12:22 Message: Logged In: YES user_id=357491 Well then, is there any desire to bother to make this happen? Or is this just a "I hope someone likes this idea enough to implement it" instance in which case this should probably be made an RFE. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-28 22:59 Message: Logged In: YES user_id=31435 mktime() interprets its argument as local time; timegm() as UTC. Generally speaking, time.mktime(time.localtime()) returns int(time.time()), and so does calendar.timegm(time.gmtime()) The OP appears to be right that the time module doesn't have an "inverse" for time.gmtime() in this sense. Then again, the time functions inherited from C are generally a twisted thicket. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2003-05-28 21:50 Message: Logged In: YES user_id=357491 OK, assuming the OP meant calendar.timegm , doesn't time.mktime provide the same functionality? Or is the desire to have it because it specifies the epoch as 1970-01-01? ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2003-05-23 00:47 Message: Logged In: YES user_id=31435 I expect the OP meant the calendar.timegm() function. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2003-05-22 17:46 Message: Logged In: YES user_id=33168 The gmtime function is in time, not calendar. Did you mean the opposite that you believe gmtime should be in calendar? gmtime comes from the C version which is the purpose of time, to expose C functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=697985&group_id=5470 From noreply at sourceforge.net Fri Nov 10 21:55:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Nov 2006 12:55:31 -0800 Subject: [ python-Bugs-1580563 ] "make install" for Python 2.4.4 not working properly Message-ID: Bugs item #1580563, was opened at 2006-10-19 10:21 Message generated for change (Comment added) made by erflynn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: "make install" for Python 2.4.4 not working properly Initial Comment: Running "make install" on Linux (Suse 10.1) won't terminate properly: Compiling /opt/python-2.4.4/lib/python2.4/user.py ... Compiling /opt/python-2.4.4/lib/python2.4/uu.py ... Compiling /opt/python-2.4.4/lib/python2.4/warnings.py ... Compiling /opt/python-2.4.4/lib/python2.4/wave.py ... Compiling /opt/python-2.4.4/lib/python2.4/weakref.py ... Compiling /opt/python-2.4.4/lib/python2.4/webbrowser.py ... Compiling /opt/python-2.4.4/lib/python2.4/whichdb.py ... Compiling /opt/python-2.4.4/lib/python2.4/whrandom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xdrlib.py ... Listing /opt/python-2.4.4/lib/python2.4/xml ... Compiling /opt/python-2.4.4/lib/python2.4/xml/__init__.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/dom ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/NodeFilter.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/domreg.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/expatbuilder.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/minicompat.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/minidom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/pulldom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/xmlbuilder.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/parsers ... Compiling /opt/python-2.4.4/lib/python2.4/xml/parsers/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/parsers/expat.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/sax ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/_exceptions.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/expatreader.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/handler.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/saxutils.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/xmlreader.py ... Compiling /opt/python-2.4.4/lib/python2.4/xmllib.py ... Compiling /opt/python-2.4.4/lib/python2.4/xmlrpclib.py ... Compiling /opt/python-2.4.4/lib/python2.4/zipfile.py ... make: *** [libinstall] Error 1 ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-10 15:55 Message: Logged In: YES user_id=1642549 Hi, I am having exactly the same issue on Python 2.5. configure arguments have nothing special. This was on a Debian Woody system on which I have an account but not root access. Please let me know what to do in order to supply more information. ~Evan ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-20 03:52 Message: Logged In: YES user_id=21627 I can't reproduce this. It installs fine for me (although I try to install to /tmp/python-2.4.4, not opt), and also not on SuSE, but Debian unstable. Can you please debug through compileall, to find out whether and how exit_status gets set to a non-zero value? For that to happen, success should be set to 0 at some point. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2006-10-19 14:00 Message: Logged In: YES user_id=11084 On both system just "configure --prefix=/opt/python-2.4.4" ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-19 13:26 Message: Logged In: YES user_id=580910 What are the configure arguments that you are using? ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2006-10-19 10:33 Message: Logged In: YES user_id=11084 Same issue on MacOSX ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470 From noreply at sourceforge.net Sat Nov 11 00:52:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 10 Nov 2006 15:52:08 -0800 Subject: [ python-Bugs-1580563 ] "make install" for Python 2.4.4 not working properly Message-ID: Bugs item #1580563, was opened at 2006-10-19 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=1580563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: "make install" for Python 2.4.4 not working properly Initial Comment: Running "make install" on Linux (Suse 10.1) won't terminate properly: Compiling /opt/python-2.4.4/lib/python2.4/user.py ... Compiling /opt/python-2.4.4/lib/python2.4/uu.py ... Compiling /opt/python-2.4.4/lib/python2.4/warnings.py ... Compiling /opt/python-2.4.4/lib/python2.4/wave.py ... Compiling /opt/python-2.4.4/lib/python2.4/weakref.py ... Compiling /opt/python-2.4.4/lib/python2.4/webbrowser.py ... Compiling /opt/python-2.4.4/lib/python2.4/whichdb.py ... Compiling /opt/python-2.4.4/lib/python2.4/whrandom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xdrlib.py ... Listing /opt/python-2.4.4/lib/python2.4/xml ... Compiling /opt/python-2.4.4/lib/python2.4/xml/__init__.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/dom ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/NodeFilter.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/domreg.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/expatbuilder.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/minicompat.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/minidom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/pulldom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/xmlbuilder.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/parsers ... Compiling /opt/python-2.4.4/lib/python2.4/xml/parsers/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/parsers/expat.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/sax ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/_exceptions.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/expatreader.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/handler.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/saxutils.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/xmlreader.py ... Compiling /opt/python-2.4.4/lib/python2.4/xmllib.py ... Compiling /opt/python-2.4.4/lib/python2.4/xmlrpclib.py ... Compiling /opt/python-2.4.4/lib/python2.4/zipfile.py ... make: *** [libinstall] Error 1 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-11 00:52 Message: Logged In: YES user_id=21627 Can you please provide a *complete* log file (i.e. terminal output) of the "make install" run? If SF rejects it because it is too large, try compressing it. ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-10 21:55 Message: Logged In: YES user_id=1642549 Hi, I am having exactly the same issue on Python 2.5. configure arguments have nothing special. This was on a Debian Woody system on which I have an account but not root access. Please let me know what to do in order to supply more information. ~Evan ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-20 09:52 Message: Logged In: YES user_id=21627 I can't reproduce this. It installs fine for me (although I try to install to /tmp/python-2.4.4, not opt), and also not on SuSE, but Debian unstable. Can you please debug through compileall, to find out whether and how exit_status gets set to a non-zero value? For that to happen, success should be set to 0 at some point. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2006-10-19 20:00 Message: Logged In: YES user_id=11084 On both system just "configure --prefix=/opt/python-2.4.4" ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-19 19:26 Message: Logged In: YES user_id=580910 What are the configure arguments that you are using? ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2006-10-19 16:33 Message: Logged In: YES user_id=11084 Same issue on MacOSX ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470 From noreply at sourceforge.net Sat Nov 11 17:35:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Nov 2006 08:35:15 -0800 Subject: [ python-Bugs-1594742 ] Word should be changed on page 3.6.1 Message-ID: Bugs item #1594742, was opened at 2006-11-11 10:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594742&group_id=5470 Please note that this 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 Private: No Submitted By: jikanter (jikanter) Assigned to: Nobody/Anonymous (nobody) Summary: Word should be changed on page 3.6.1 Initial Comment: The documentation currently reads as follows: startswith( prefix[, start[, end]]) Return True if string starts with the prefix, otherwise return False. prefix can also be a tuple of suffixes to look for. With optional start, test string beginning at that position. With optional end, stop comparing string at that position. Changed in version 2.5: Accept tuples as prefix. I believe that in the line that starts with "prefix can also...", the word suffixes should be changed to the word prefixes. Thanks for all the good work. Let me know if you have any questions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594742&group_id=5470 From noreply at sourceforge.net Sat Nov 11 18:37:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Nov 2006 09:37:49 -0800 Subject: [ python-Bugs-1594758 ] Make docu for dict.update more clear Message-ID: Bugs item #1594758, was opened at 2006-11-11 18: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=1594758&group_id=5470 Please note that this 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 Private: No Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Make docu for dict.update more clear Initial Comment: In Note (9) to the mapping types documentation (http://docs.python.org/lib/typesmapping.html), it should be mentioned that dict.update returns None to remind you that it changes the dict in place. Also, the description should more precisely say "updates (and overwrites) `a` with key/value pairs from `b`" instead of "updates (and overwrites) key/value pairs from `b`". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594758&group_id=5470 From noreply at sourceforge.net Sat Nov 11 18:38:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Nov 2006 09:38:12 -0800 Subject: [ python-Bugs-1594758 ] Make docu for dict.update more clear Message-ID: Bugs item #1594758, was opened at 2006-11-11 18:37 Message generated for change (Settings changed) made by cito You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594758&group_id=5470 Please note that this 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: 1 Private: No Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: Make docu for dict.update more clear Initial Comment: In Note (9) to the mapping types documentation (http://docs.python.org/lib/typesmapping.html), it should be mentioned that dict.update returns None to remind you that it changes the dict in place. Also, the description should more precisely say "updates (and overwrites) `a` with key/value pairs from `b`" instead of "updates (and overwrites) key/value pairs from `b`". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594758&group_id=5470 From noreply at sourceforge.net Sat Nov 11 19:29:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Nov 2006 10:29:26 -0800 Subject: [ python-Bugs-1594742 ] Word should be changed on page 3.6.1 Message-ID: Bugs item #1594742, was opened at 2006-11-11 16:35 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594742&group_id=5470 Please note that this 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 Private: No Submitted By: jikanter (jikanter) >Assigned to: Georg Brandl (gbrandl) Summary: Word should be changed on page 3.6.1 Initial Comment: The documentation currently reads as follows: startswith( prefix[, start[, end]]) Return True if string starts with the prefix, otherwise return False. prefix can also be a tuple of suffixes to look for. With optional start, test string beginning at that position. With optional end, stop comparing string at that position. Changed in version 2.5: Accept tuples as prefix. I believe that in the line that starts with "prefix can also...", the word suffixes should be changed to the word prefixes. Thanks for all the good work. Let me know if you have any questions. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-11 18:29 Message: Logged In: YES user_id=849994 Thanks for spotting this, fixed in rev. 52731, 52732 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594742&group_id=5470 From noreply at sourceforge.net Sat Nov 11 19:33:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Nov 2006 10:33:19 -0800 Subject: [ python-Bugs-1594758 ] Make docu for dict.update more clear Message-ID: Bugs item #1594758, was opened at 2006-11-11 17:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594758&group_id=5470 Please note that this 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: 1 Private: No Submitted By: Christoph Zwerschke (cito) >Assigned to: Georg Brandl (gbrandl) Summary: Make docu for dict.update more clear Initial Comment: In Note (9) to the mapping types documentation (http://docs.python.org/lib/typesmapping.html), it should be mentioned that dict.update returns None to remind you that it changes the dict in place. Also, the description should more precisely say "updates (and overwrites) `a` with key/value pairs from `b`" instead of "updates (and overwrites) key/value pairs from `b`". ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-11 18:33 Message: Logged In: YES user_id=849994 Thanks for noticing, changed in rev. 52733, 52734 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594758&group_id=5470 From noreply at sourceforge.net Sat Nov 11 21:27:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Nov 2006 12:27:26 -0800 Subject: [ python-Bugs-1594809 ] make install fails, various modules do not work Message-ID: Bugs item #1594809, was opened at 2006-11-11 15: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=1594809&group_id=5470 Please note that this 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 Private: No Submitted By: Evan (erflynn) Assigned to: Nobody/Anonymous (nobody) Summary: make install fails, various modules do not work Initial Comment: I compiled Python 2.5 on a Linux user account on Debian 3.0. configure and make seemed to go okay, but make install failed at 'zipfile.py' when it was compiling modules into bytecode. I can still use the python interpreter. However, some important modules seem to be missing such as 'time' and 'operator'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470 From noreply at sourceforge.net Sat Nov 11 21:29:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Nov 2006 12:29:04 -0800 Subject: [ python-Bugs-1580563 ] "make install" for Python 2.4.4 not working properly Message-ID: Bugs item #1580563, was opened at 2006-10-19 10:21 Message generated for change (Comment added) made by erflynn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: "make install" for Python 2.4.4 not working properly Initial Comment: Running "make install" on Linux (Suse 10.1) won't terminate properly: Compiling /opt/python-2.4.4/lib/python2.4/user.py ... Compiling /opt/python-2.4.4/lib/python2.4/uu.py ... Compiling /opt/python-2.4.4/lib/python2.4/warnings.py ... Compiling /opt/python-2.4.4/lib/python2.4/wave.py ... Compiling /opt/python-2.4.4/lib/python2.4/weakref.py ... Compiling /opt/python-2.4.4/lib/python2.4/webbrowser.py ... Compiling /opt/python-2.4.4/lib/python2.4/whichdb.py ... Compiling /opt/python-2.4.4/lib/python2.4/whrandom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xdrlib.py ... Listing /opt/python-2.4.4/lib/python2.4/xml ... Compiling /opt/python-2.4.4/lib/python2.4/xml/__init__.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/dom ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/NodeFilter.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/domreg.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/expatbuilder.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/minicompat.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/minidom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/pulldom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/xmlbuilder.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/parsers ... Compiling /opt/python-2.4.4/lib/python2.4/xml/parsers/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/parsers/expat.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/sax ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/_exceptions.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/expatreader.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/handler.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/saxutils.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/xmlreader.py ... Compiling /opt/python-2.4.4/lib/python2.4/xmllib.py ... Compiling /opt/python-2.4.4/lib/python2.4/xmlrpclib.py ... Compiling /opt/python-2.4.4/lib/python2.4/zipfile.py ... make: *** [libinstall] Error 1 ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-11 15:29 Message: Logged In: YES user_id=1642549 I created a new bug report so I could attach a file. See #1594809 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-10 18:52 Message: Logged In: YES user_id=21627 Can you please provide a *complete* log file (i.e. terminal output) of the "make install" run? If SF rejects it because it is too large, try compressing it. ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-10 15:55 Message: Logged In: YES user_id=1642549 Hi, I am having exactly the same issue on Python 2.5. configure arguments have nothing special. This was on a Debian Woody system on which I have an account but not root access. Please let me know what to do in order to supply more information. ~Evan ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-20 03:52 Message: Logged In: YES user_id=21627 I can't reproduce this. It installs fine for me (although I try to install to /tmp/python-2.4.4, not opt), and also not on SuSE, but Debian unstable. Can you please debug through compileall, to find out whether and how exit_status gets set to a non-zero value? For that to happen, success should be set to 0 at some point. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2006-10-19 14:00 Message: Logged In: YES user_id=11084 On both system just "configure --prefix=/opt/python-2.4.4" ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-19 13:26 Message: Logged In: YES user_id=580910 What are the configure arguments that you are using? ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2006-10-19 10:33 Message: Logged In: YES user_id=11084 Same issue on MacOSX ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470 From noreply at sourceforge.net Sat Nov 11 21:54:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Nov 2006 12:54:04 -0800 Subject: [ python-Bugs-1594809 ] make install fails, various modules do not work Message-ID: Bugs item #1594809, was opened at 2006-11-11 12:27 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470 Please note that this 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 Private: No Submitted By: Evan (erflynn) Assigned to: Nobody/Anonymous (nobody) Summary: make install fails, various modules do not work Initial Comment: I compiled Python 2.5 on a Linux user account on Debian 3.0. configure and make seemed to go okay, but make install failed at 'zipfile.py' when it was compiling modules into bytecode. I can still use the python interpreter. However, some important modules seem to be missing such as 'time' and 'operator'. ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-11-11 12:54 Message: Logged In: YES user_id=357491 Looking through the logs it looks like libinstall had an error. Did you run over quota in your home directory? The log for 'make' shows that 'time' was built. I bet if you run the Python executable in the directory where you compiled you will find you can import 'time' and such fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470 From noreply at sourceforge.net Sat Nov 11 22:44:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Nov 2006 13:44:21 -0800 Subject: [ python-Bugs-1594809 ] make install fails, various modules do not work Message-ID: Bugs item #1594809, was opened at 2006-11-11 15:27 Message generated for change (Comment added) made by erflynn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470 Please note that this 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 Private: No Submitted By: Evan (erflynn) Assigned to: Nobody/Anonymous (nobody) Summary: make install fails, various modules do not work Initial Comment: I compiled Python 2.5 on a Linux user account on Debian 3.0. configure and make seemed to go okay, but make install failed at 'zipfile.py' when it was compiling modules into bytecode. I can still use the python interpreter. However, some important modules seem to be missing such as 'time' and 'operator'. ---------------------------------------------------------------------- >Comment By: Evan (erflynn) Date: 2006-11-11 16:44 Message: Logged In: YES user_id=1642549 No I didn't run over quota. Running python in the directory it was built does not do anything differently. The logs indicate that 4 regression tests failed during 'make test'. This is reproducible. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-11-11 15:54 Message: Logged In: YES user_id=357491 Looking through the logs it looks like libinstall had an error. Did you run over quota in your home directory? The log for 'make' shows that 'time' was built. I bet if you run the Python executable in the directory where you compiled you will find you can import 'time' and such fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470 From noreply at sourceforge.net Sun Nov 12 01:28:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Nov 2006 16:28:19 -0800 Subject: [ python-Bugs-1594809 ] make install fails, various modules do not work Message-ID: Bugs item #1594809, was opened at 2006-11-11 21:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470 Please note that this 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 Private: No Submitted By: Evan (erflynn) Assigned to: Nobody/Anonymous (nobody) Summary: make install fails, various modules do not work Initial Comment: I compiled Python 2.5 on a Linux user account on Debian 3.0. configure and make seemed to go okay, but make install failed at 'zipfile.py' when it was compiling modules into bytecode. I can still use the python interpreter. However, some important modules seem to be missing such as 'time' and 'operator'. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 01:28 Message: Logged In: YES user_id=21627 I think I know what the cause of the problem is (although not the root cause): Compiling /home/cs/csugrads/erflynn/stow/python/lib/python2.5/test/test_multibytecodec.py ... Sorry: UnicodeError: ("\\N escapes not supported (can't load unicodedata module)",) So compilation for test_multibytecodec fails, causing compileall to fail. In the build directory, can you please run PYTHONPATH=/home/cs/csugrads/erflynn/stow/python/lib/python2.5 ./python -Wi -tt and do import unicodedata print unicodedata.ucnhash_CAPI import test.test_multibytecodec and report its output? ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-11 22:44 Message: Logged In: YES user_id=1642549 No I didn't run over quota. Running python in the directory it was built does not do anything differently. The logs indicate that 4 regression tests failed during 'make test'. This is reproducible. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-11-11 21:54 Message: Logged In: YES user_id=357491 Looking through the logs it looks like libinstall had an error. Did you run over quota in your home directory? The log for 'make' shows that 'time' was built. I bet if you run the Python executable in the directory where you compiled you will find you can import 'time' and such fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470 From noreply at sourceforge.net Sun Nov 12 02:12:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Nov 2006 17:12:49 -0800 Subject: [ python-Bugs-1594809 ] make install fails, various modules do not work Message-ID: Bugs item #1594809, was opened at 2006-11-11 15:27 Message generated for change (Comment added) made by erflynn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470 Please note that this 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 Private: No Submitted By: Evan (erflynn) Assigned to: Nobody/Anonymous (nobody) Summary: make install fails, various modules do not work Initial Comment: I compiled Python 2.5 on a Linux user account on Debian 3.0. configure and make seemed to go okay, but make install failed at 'zipfile.py' when it was compiling modules into bytecode. I can still use the python interpreter. However, some important modules seem to be missing such as 'time' and 'operator'. ---------------------------------------------------------------------- >Comment By: Evan (erflynn) Date: 2006-11-11 20:12 Message: Logged In: YES user_id=1642549 It could be a good start... erflynn at squall 267>./python -Wi -tt Python 2.5 (r25:51908, Nov 10 2006, 20:10:11) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import unicodedata Traceback (most recent call last): File "", line 1, in ImportError: No module named unicodedata >>> Maybe it's not linking some modules in? Would it be helpful if I let you SSH to the box? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-11 19:28 Message: Logged In: YES user_id=21627 I think I know what the cause of the problem is (although not the root cause): Compiling /home/cs/csugrads/erflynn/stow/python/lib/python2.5/test/test_multibytecodec.py ... Sorry: UnicodeError: ("\\N escapes not supported (can't load unicodedata module)",) So compilation for test_multibytecodec fails, causing compileall to fail. In the build directory, can you please run PYTHONPATH=/home/cs/csugrads/erflynn/stow/python/lib/python2.5 ./python -Wi -tt and do import unicodedata print unicodedata.ucnhash_CAPI import test.test_multibytecodec and report its output? ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-11 16:44 Message: Logged In: YES user_id=1642549 No I didn't run over quota. Running python in the directory it was built does not do anything differently. The logs indicate that 4 regression tests failed during 'make test'. This is reproducible. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-11-11 15:54 Message: Logged In: YES user_id=357491 Looking through the logs it looks like libinstall had an error. Did you run over quota in your home directory? The log for 'make' shows that 'time' was built. I bet if you run the Python executable in the directory where you compiled you will find you can import 'time' and such fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470 From noreply at sourceforge.net Sun Nov 12 09:31:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 00:31:52 -0800 Subject: [ python-Bugs-1594966 ] doctest simple usage recipe is misleading Message-ID: Bugs item #1594966, was opened at 2006-11-12 10: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=1594966&group_id=5470 Please note that this 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 Private: No Submitted By: Ken Rimey (yemir) Assigned to: Nobody/Anonymous (nobody) Summary: doctest simple usage recipe is misleading Initial Comment: "23.2.1 Simple Usage: Checking Examples in Docstrings" sets up a trap for the unsuspecting developer: http://docs.python.org/lib/doctest-simple-testmod.html That page recommends adding the following code to the end of a module using doctest: def _test(): import doctest doctest.testmod() if __name__ == "__main__": _test() The problem is that a reasonable person will figure that _test() has been defined for convenience in executing the tests from other Python code as follows: import M M._test() However, that executes the doctests found in __main__, not M! I think the recommended recipe should instead be as follows: if __name__ == "__main__": import doctest doctest.testmod() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594966&group_id=5470 From noreply at sourceforge.net Sun Nov 12 10:57:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 01:57:24 -0800 Subject: [ python-Bugs-1594809 ] make install fails, various modules do not work Message-ID: Bugs item #1594809, was opened at 2006-11-11 21:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470 Please note that this 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 Private: No Submitted By: Evan (erflynn) Assigned to: Nobody/Anonymous (nobody) Summary: make install fails, various modules do not work Initial Comment: I compiled Python 2.5 on a Linux user account on Debian 3.0. configure and make seemed to go okay, but make install failed at 'zipfile.py' when it was compiling modules into bytecode. I can still use the python interpreter. However, some important modules seem to be missing such as 'time' and 'operator'. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 10:57 Message: Logged In: YES user_id=21627 Can you please do file build/lib.linux-i686-2.5/unicodedata.so and also, in ./python print sys.path According to your make.log, unicodedata.so ought to be present. ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-12 02:12 Message: Logged In: YES user_id=1642549 It could be a good start... erflynn at squall 267>./python -Wi -tt Python 2.5 (r25:51908, Nov 10 2006, 20:10:11) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import unicodedata Traceback (most recent call last): File "", line 1, in ImportError: No module named unicodedata >>> Maybe it's not linking some modules in? Would it be helpful if I let you SSH to the box? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 01:28 Message: Logged In: YES user_id=21627 I think I know what the cause of the problem is (although not the root cause): Compiling /home/cs/csugrads/erflynn/stow/python/lib/python2.5/test/test_multibytecodec.py ... Sorry: UnicodeError: ("\\N escapes not supported (can't load unicodedata module)",) So compilation for test_multibytecodec fails, causing compileall to fail. In the build directory, can you please run PYTHONPATH=/home/cs/csugrads/erflynn/stow/python/lib/python2.5 ./python -Wi -tt and do import unicodedata print unicodedata.ucnhash_CAPI import test.test_multibytecodec and report its output? ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-11 22:44 Message: Logged In: YES user_id=1642549 No I didn't run over quota. Running python in the directory it was built does not do anything differently. The logs indicate that 4 regression tests failed during 'make test'. This is reproducible. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-11-11 21:54 Message: Logged In: YES user_id=357491 Looking through the logs it looks like libinstall had an error. Did you run over quota in your home directory? The log for 'make' shows that 'time' was built. I bet if you run the Python executable in the directory where you compiled you will find you can import 'time' and such fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470 From noreply at sourceforge.net Sun Nov 12 11:42:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 02:42:39 -0800 Subject: [ python-Bugs-1316069 ] gzip.GzipFile.seek missing second argument Message-ID: Bugs item #1316069, was opened at 2005-10-07 21:34 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1316069&group_id=5470 Please note that this 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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Neil Schemenauer (nascheme) Assigned to: Nobody/Anonymous (nobody) Summary: gzip.GzipFile.seek missing second argument Initial Comment: It would nice if GzipFile.seek matched file.seek and BZ2File.seek and took a second argument. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 11:42 Message: Logged In: YES user_id=21627 This was fixed with said patch, in r52737. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2005-11-13 11:45 Message: Logged In: YES user_id=21627 Patches can (and should) be attached to the bugs if possible. With SF access control, only the submitter and a patch admin may do so, though. ---------------------------------------------------------------------- Comment By: Fredrik Lundh (effbot) Date: 2005-11-12 11:57 Message: Logged In: YES user_id=38376 I've posted a trivial patch over at www.python.org/sf/1355023 (can patches be attached to bugs, or do we always want them over at the patch tracker?) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1316069&group_id=5470 From noreply at sourceforge.net Sun Nov 12 14:14:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 05:14:19 -0800 Subject: [ python-Bugs-1595045 ] smtplib.SMTP.sendmail() does not provide transparency Message-ID: Bugs item #1595045, was opened at 2006-11-12 15:14 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Avi Kivity (avik) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib.SMTP.sendmail() does not provide transparency Initial Comment: If the msg parameter to smtplib.SMTP.sendmail() contains a '\r\n.\r\n', the message will be terminated. This will surprise most users, as smtplib should encapsulate the various protocol details rather than expose them. It's also a potential security hole. If user-supplied data is passed as msg, then the user may be able to inject SMTP commands by placing them after a '\r\n.\r\n'. A workaround is to mutilate msg before passing it to smtplib. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&group_id=5470 From noreply at sourceforge.net Sun Nov 12 20:15:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 11:15:40 -0800 Subject: [ python-Bugs-1595164 ] texinfo library documentation fails to build Message-ID: Bugs item #1595164, was opened at 2006-11-12 19: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=1595164&group_id=5470 Please note that this 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 Private: No Submitted By: Mark Diekhans (diekhans) Assigned to: Nobody/Anonymous (nobody) Summary: texinfo library documentation fails to build Initial Comment: Attempting to build the texinfo documentation generates the error (args-out-of-range 2931944 2931946). This occurs in download of 2.5 latex doc and from trunk of svn tree. elisp stack trace attached. It would be really nice if texinfo doc was still available for download. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595164&group_id=5470 From noreply at sourceforge.net Sun Nov 12 22:03:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 13:03:42 -0800 Subject: [ python-Bugs-1594809 ] make install fails, various modules do not work Message-ID: Bugs item #1594809, was opened at 2006-11-11 15:27 Message generated for change (Comment added) made by erflynn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470 Please note that this 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 Private: No Submitted By: Evan (erflynn) Assigned to: Nobody/Anonymous (nobody) Summary: make install fails, various modules do not work Initial Comment: I compiled Python 2.5 on a Linux user account on Debian 3.0. configure and make seemed to go okay, but make install failed at 'zipfile.py' when it was compiling modules into bytecode. I can still use the python interpreter. However, some important modules seem to be missing such as 'time' and 'operator'. ---------------------------------------------------------------------- >Comment By: Evan (erflynn) Date: 2006-11-12 16:03 Message: Logged In: YES user_id=1642549 As I understand it, these modules are actually shared libraries or 'extensions'. I unset PYTHONPATH and PYTHONHOME, and the build and install went just fine. Arrgh. I wonder why I had to set them in the first place... Thanks for the help. I'm not sure what the protocol is for creating source builds, but it might be nice if in the future the source distribution would (a) run compileall during make and not make install and (b) try to rely more on configure options and not environment variables. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 04:57 Message: Logged In: YES user_id=21627 Can you please do file build/lib.linux-i686-2.5/unicodedata.so and also, in ./python print sys.path According to your make.log, unicodedata.so ought to be present. ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-11 20:12 Message: Logged In: YES user_id=1642549 It could be a good start... erflynn at squall 267>./python -Wi -tt Python 2.5 (r25:51908, Nov 10 2006, 20:10:11) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import unicodedata Traceback (most recent call last): File "", line 1, in ImportError: No module named unicodedata >>> Maybe it's not linking some modules in? Would it be helpful if I let you SSH to the box? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-11 19:28 Message: Logged In: YES user_id=21627 I think I know what the cause of the problem is (although not the root cause): Compiling /home/cs/csugrads/erflynn/stow/python/lib/python2.5/test/test_multibytecodec.py ... Sorry: UnicodeError: ("\\N escapes not supported (can't load unicodedata module)",) So compilation for test_multibytecodec fails, causing compileall to fail. In the build directory, can you please run PYTHONPATH=/home/cs/csugrads/erflynn/stow/python/lib/python2.5 ./python -Wi -tt and do import unicodedata print unicodedata.ucnhash_CAPI import test.test_multibytecodec and report its output? ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-11 16:44 Message: Logged In: YES user_id=1642549 No I didn't run over quota. Running python in the directory it was built does not do anything differently. The logs indicate that 4 regression tests failed during 'make test'. This is reproducible. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-11-11 15:54 Message: Logged In: YES user_id=357491 Looking through the logs it looks like libinstall had an error. Did you run over quota in your home directory? The log for 'make' shows that 'time' was built. I bet if you run the Python executable in the directory where you compiled you will find you can import 'time' and such fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470 From noreply at sourceforge.net Sun Nov 12 22:33:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 13:33:11 -0800 Subject: [ python-Bugs-1594809 ] make install fails, various modules do not work Message-ID: Bugs item #1594809, was opened at 2006-11-11 21:27 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470 Please note that this 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: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Evan (erflynn) Assigned to: Nobody/Anonymous (nobody) Summary: make install fails, various modules do not work Initial Comment: I compiled Python 2.5 on a Linux user account on Debian 3.0. configure and make seemed to go okay, but make install failed at 'zipfile.py' when it was compiling modules into bytecode. I can still use the python interpreter. However, some important modules seem to be missing such as 'time' and 'operator'. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 22:33 Message: Logged In: YES user_id=21627 Ok, closing this as "works for me" - if you set PYTHON* while building Python, you are on your own - don't do that, then. AFAICT, (a) running compileall during make would not have helped, it still would not have found the correct unicodedata module. (b) the installation doesn't rely on environment variables; as you found, they actually hurt. ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-12 22:03 Message: Logged In: YES user_id=1642549 As I understand it, these modules are actually shared libraries or 'extensions'. I unset PYTHONPATH and PYTHONHOME, and the build and install went just fine. Arrgh. I wonder why I had to set them in the first place... Thanks for the help. I'm not sure what the protocol is for creating source builds, but it might be nice if in the future the source distribution would (a) run compileall during make and not make install and (b) try to rely more on configure options and not environment variables. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 10:57 Message: Logged In: YES user_id=21627 Can you please do file build/lib.linux-i686-2.5/unicodedata.so and also, in ./python print sys.path According to your make.log, unicodedata.so ought to be present. ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-12 02:12 Message: Logged In: YES user_id=1642549 It could be a good start... erflynn at squall 267>./python -Wi -tt Python 2.5 (r25:51908, Nov 10 2006, 20:10:11) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import unicodedata Traceback (most recent call last): File "", line 1, in ImportError: No module named unicodedata >>> Maybe it's not linking some modules in? Would it be helpful if I let you SSH to the box? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 01:28 Message: Logged In: YES user_id=21627 I think I know what the cause of the problem is (although not the root cause): Compiling /home/cs/csugrads/erflynn/stow/python/lib/python2.5/test/test_multibytecodec.py ... Sorry: UnicodeError: ("\\N escapes not supported (can't load unicodedata module)",) So compilation for test_multibytecodec fails, causing compileall to fail. In the build directory, can you please run PYTHONPATH=/home/cs/csugrads/erflynn/stow/python/lib/python2.5 ./python -Wi -tt and do import unicodedata print unicodedata.ucnhash_CAPI import test.test_multibytecodec and report its output? ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-11 22:44 Message: Logged In: YES user_id=1642549 No I didn't run over quota. Running python in the directory it was built does not do anything differently. The logs indicate that 4 regression tests failed during 'make test'. This is reproducible. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-11-11 21:54 Message: Logged In: YES user_id=357491 Looking through the logs it looks like libinstall had an error. Did you run over quota in your home directory? The log for 'make' shows that 'time' was built. I bet if you run the Python executable in the directory where you compiled you will find you can import 'time' and such fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470 From noreply at sourceforge.net Sun Nov 12 22:34:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 13:34:19 -0800 Subject: [ python-Bugs-1580563 ] "make install" for Python 2.4.4 not working properly Message-ID: Bugs item #1580563, was opened at 2006-10-19 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=1580563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: "make install" for Python 2.4.4 not working properly Initial Comment: Running "make install" on Linux (Suse 10.1) won't terminate properly: Compiling /opt/python-2.4.4/lib/python2.4/user.py ... Compiling /opt/python-2.4.4/lib/python2.4/uu.py ... Compiling /opt/python-2.4.4/lib/python2.4/warnings.py ... Compiling /opt/python-2.4.4/lib/python2.4/wave.py ... Compiling /opt/python-2.4.4/lib/python2.4/weakref.py ... Compiling /opt/python-2.4.4/lib/python2.4/webbrowser.py ... Compiling /opt/python-2.4.4/lib/python2.4/whichdb.py ... Compiling /opt/python-2.4.4/lib/python2.4/whrandom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xdrlib.py ... Listing /opt/python-2.4.4/lib/python2.4/xml ... Compiling /opt/python-2.4.4/lib/python2.4/xml/__init__.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/dom ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/NodeFilter.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/domreg.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/expatbuilder.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/minicompat.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/minidom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/pulldom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/xmlbuilder.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/parsers ... Compiling /opt/python-2.4.4/lib/python2.4/xml/parsers/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/parsers/expat.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/sax ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/_exceptions.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/expatreader.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/handler.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/saxutils.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/xmlreader.py ... Compiling /opt/python-2.4.4/lib/python2.4/xmllib.py ... Compiling /opt/python-2.4.4/lib/python2.4/xmlrpclib.py ... Compiling /opt/python-2.4.4/lib/python2.4/zipfile.py ... make: *** [libinstall] Error 1 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 22:34 Message: Logged In: YES user_id=21627 ajung: can you please report what environment settings you are using? If you have set PYTHON* in your environment, make sure to unset all these variables. ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-11 21:29 Message: Logged In: YES user_id=1642549 I created a new bug report so I could attach a file. See #1594809 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-11 00:52 Message: Logged In: YES user_id=21627 Can you please provide a *complete* log file (i.e. terminal output) of the "make install" run? If SF rejects it because it is too large, try compressing it. ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-10 21:55 Message: Logged In: YES user_id=1642549 Hi, I am having exactly the same issue on Python 2.5. configure arguments have nothing special. This was on a Debian Woody system on which I have an account but not root access. Please let me know what to do in order to supply more information. ~Evan ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-20 09:52 Message: Logged In: YES user_id=21627 I can't reproduce this. It installs fine for me (although I try to install to /tmp/python-2.4.4, not opt), and also not on SuSE, but Debian unstable. Can you please debug through compileall, to find out whether and how exit_status gets set to a non-zero value? For that to happen, success should be set to 0 at some point. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2006-10-19 20:00 Message: Logged In: YES user_id=11084 On both system just "configure --prefix=/opt/python-2.4.4" ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-19 19:26 Message: Logged In: YES user_id=580910 What are the configure arguments that you are using? ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2006-10-19 16:33 Message: Logged In: YES user_id=11084 Same issue on MacOSX ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470 From noreply at sourceforge.net Sun Nov 12 22:47:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 13:47:46 -0800 Subject: [ python-Bugs-1595164 ] texinfo library documentation fails to build Message-ID: Bugs item #1595164, was opened at 2006-11-12 20:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595164&group_id=5470 Please note that this 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 Private: No Submitted By: Mark Diekhans (diekhans) Assigned to: Nobody/Anonymous (nobody) Summary: texinfo library documentation fails to build Initial Comment: Attempting to build the texinfo documentation generates the error (args-out-of-range 2931944 2931946). This occurs in download of 2.5 latex doc and from trunk of svn tree. elisp stack trace attached. It would be really nice if texinfo doc was still available for download. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 22:47 Message: Logged In: YES user_id=21627 Can you find out what is causing this error? If not, would you be interested in rewriting this in Python? (AFAICT, there really is no reason that this conversion is written in elisp) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595164&group_id=5470 From noreply at sourceforge.net Sun Nov 12 22:56:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 13:56:23 -0800 Subject: [ python-Bugs-1595045 ] smtplib.SMTP.sendmail() does not provide transparency Message-ID: Bugs item #1595045, was opened at 2006-11-12 14:14 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Avi Kivity (avik) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib.SMTP.sendmail() does not provide transparency Initial Comment: If the msg parameter to smtplib.SMTP.sendmail() contains a '\r\n.\r\n', the message will be terminated. This will surprise most users, as smtplib should encapsulate the various protocol details rather than expose them. It's also a potential security hole. If user-supplied data is passed as msg, then the user may be able to inject SMTP commands by placing them after a '\r\n.\r\n'. A workaround is to mutilate msg before passing it to smtplib. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 22:56 Message: Logged In: YES user_id=21627 Would you like to contribute a patch to fix this problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&group_id=5470 From noreply at sourceforge.net Sun Nov 12 22:57:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 13:57:12 -0800 Subject: [ python-Bugs-1594809 ] make install fails, various modules do not work Message-ID: Bugs item #1594809, was opened at 2006-11-11 15:27 Message generated for change (Comment added) made by erflynn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470 Please note that this 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: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Evan (erflynn) Assigned to: Nobody/Anonymous (nobody) Summary: make install fails, various modules do not work Initial Comment: I compiled Python 2.5 on a Linux user account on Debian 3.0. configure and make seemed to go okay, but make install failed at 'zipfile.py' when it was compiling modules into bytecode. I can still use the python interpreter. However, some important modules seem to be missing such as 'time' and 'operator'. ---------------------------------------------------------------------- >Comment By: Evan (erflynn) Date: 2006-11-12 16:57 Message: Logged In: YES user_id=1642549 OK but there should be a note about this in the README: something like "if you are reinstalling Python or upgrading to a newer version, make sure to unset PYTHONHOME and PYTHONPATH." Or have the makefile use "python -E" while building Python. It is pretty strange to see a "make" run fine but the "make install" bombs. If you move compileall to the "make" stage, then you would know sooner if there was a problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 16:33 Message: Logged In: YES user_id=21627 Ok, closing this as "works for me" - if you set PYTHON* while building Python, you are on your own - don't do that, then. AFAICT, (a) running compileall during make would not have helped, it still would not have found the correct unicodedata module. (b) the installation doesn't rely on environment variables; as you found, they actually hurt. ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-12 16:03 Message: Logged In: YES user_id=1642549 As I understand it, these modules are actually shared libraries or 'extensions'. I unset PYTHONPATH and PYTHONHOME, and the build and install went just fine. Arrgh. I wonder why I had to set them in the first place... Thanks for the help. I'm not sure what the protocol is for creating source builds, but it might be nice if in the future the source distribution would (a) run compileall during make and not make install and (b) try to rely more on configure options and not environment variables. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 04:57 Message: Logged In: YES user_id=21627 Can you please do file build/lib.linux-i686-2.5/unicodedata.so and also, in ./python print sys.path According to your make.log, unicodedata.so ought to be present. ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-11 20:12 Message: Logged In: YES user_id=1642549 It could be a good start... erflynn at squall 267>./python -Wi -tt Python 2.5 (r25:51908, Nov 10 2006, 20:10:11) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import unicodedata Traceback (most recent call last): File "", line 1, in ImportError: No module named unicodedata >>> Maybe it's not linking some modules in? Would it be helpful if I let you SSH to the box? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-11 19:28 Message: Logged In: YES user_id=21627 I think I know what the cause of the problem is (although not the root cause): Compiling /home/cs/csugrads/erflynn/stow/python/lib/python2.5/test/test_multibytecodec.py ... Sorry: UnicodeError: ("\\N escapes not supported (can't load unicodedata module)",) So compilation for test_multibytecodec fails, causing compileall to fail. In the build directory, can you please run PYTHONPATH=/home/cs/csugrads/erflynn/stow/python/lib/python2.5 ./python -Wi -tt and do import unicodedata print unicodedata.ucnhash_CAPI import test.test_multibytecodec and report its output? ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-11 16:44 Message: Logged In: YES user_id=1642549 No I didn't run over quota. Running python in the directory it was built does not do anything differently. The logs indicate that 4 regression tests failed during 'make test'. This is reproducible. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-11-11 15:54 Message: Logged In: YES user_id=357491 Looking through the logs it looks like libinstall had an error. Did you run over quota in your home directory? The log for 'make' shows that 'time' was built. I bet if you run the Python executable in the directory where you compiled you will find you can import 'time' and such fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470 From noreply at sourceforge.net Sun Nov 12 23:00:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 14:00:53 -0800 Subject: [ python-Bugs-1595045 ] smtplib.SMTP.sendmail() does not provide transparency Message-ID: Bugs item #1595045, was opened at 2006-11-12 15:14 Message generated for change (Comment added) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Avi Kivity (avik) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib.SMTP.sendmail() does not provide transparency Initial Comment: If the msg parameter to smtplib.SMTP.sendmail() contains a '\r\n.\r\n', the message will be terminated. This will surprise most users, as smtplib should encapsulate the various protocol details rather than expose them. It's also a potential security hole. If user-supplied data is passed as msg, then the user may be able to inject SMTP commands by placing them after a '\r\n.\r\n'. A workaround is to mutilate msg before passing it to smtplib. ---------------------------------------------------------------------- >Comment By: Avi Kivity (avik) Date: 2006-11-13 00:00 Message: Logged In: YES user_id=539971 Yes. Do I need to submit it against 2.4 or 2.5, or both? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 23:56 Message: Logged In: YES user_id=21627 Would you like to contribute a patch to fix this problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&group_id=5470 From noreply at sourceforge.net Sun Nov 12 23:07:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 14:07:50 -0800 Subject: [ python-Bugs-1595045 ] smtplib.SMTP.sendmail() does not provide transparency Message-ID: Bugs item #1595045, was opened at 2006-11-12 13:14 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Avi Kivity (avik) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib.SMTP.sendmail() does not provide transparency Initial Comment: If the msg parameter to smtplib.SMTP.sendmail() contains a '\r\n.\r\n', the message will be terminated. This will surprise most users, as smtplib should encapsulate the various protocol details rather than expose them. It's also a potential security hole. If user-supplied data is passed as msg, then the user may be able to inject SMTP commands by placing them after a '\r\n.\r\n'. A workaround is to mutilate msg before passing it to smtplib. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-12 22:07 Message: Logged In: YES user_id=849994 As there were almost no changes in smtplib between 2.4 and 2.5, I think that 2.5 is enough, if someone backports it to 2.4, he can adapt if necessary. ---------------------------------------------------------------------- Comment By: Avi Kivity (avik) Date: 2006-11-12 22:00 Message: Logged In: YES user_id=539971 Yes. Do I need to submit it against 2.4 or 2.5, or both? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 21:56 Message: Logged In: YES user_id=21627 Would you like to contribute a patch to fix this problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&group_id=5470 From noreply at sourceforge.net Mon Nov 13 00:05:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 15:05:12 -0800 Subject: [ python-Bugs-1595045 ] smtplib.SMTP.sendmail() does not provide transparency Message-ID: Bugs item #1595045, was opened at 2006-11-12 15:14 Message generated for change (Comment added) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Avi Kivity (avik) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib.SMTP.sendmail() does not provide transparency Initial Comment: If the msg parameter to smtplib.SMTP.sendmail() contains a '\r\n.\r\n', the message will be terminated. This will surprise most users, as smtplib should encapsulate the various protocol details rather than expose them. It's also a potential security hole. If user-supplied data is passed as msg, then the user may be able to inject SMTP commands by placing them after a '\r\n.\r\n'. A workaround is to mutilate msg before passing it to smtplib. ---------------------------------------------------------------------- >Comment By: Avi Kivity (avik) Date: 2006-11-13 01:05 Message: Logged In: YES user_id=539971 Sorry, the report is completely bogus. smtplib already does the necessary quoting. I was getting truncated emails from a subversion commit hook, and jumped to conclusions. Turned out the commit hook was using the sendmail command, NOT smtplib (although it does have that option). Sorry for the noise. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-13 00:07 Message: Logged In: YES user_id=849994 As there were almost no changes in smtplib between 2.4 and 2.5, I think that 2.5 is enough, if someone backports it to 2.4, he can adapt if necessary. ---------------------------------------------------------------------- Comment By: Avi Kivity (avik) Date: 2006-11-13 00:00 Message: Logged In: YES user_id=539971 Yes. Do I need to submit it against 2.4 or 2.5, or both? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 23:56 Message: Logged In: YES user_id=21627 Would you like to contribute a patch to fix this problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&group_id=5470 From noreply at sourceforge.net Mon Nov 13 00:06:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 15:06:18 -0800 Subject: [ python-Bugs-1595045 ] smtplib.SMTP.sendmail() does not provide transparency Message-ID: Bugs item #1595045, was opened at 2006-11-12 15:14 Message generated for change (Comment added) made by avik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&group_id=5470 Please note that this message will contain 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: Deleted Resolution: None Priority: 5 Private: No Submitted By: Avi Kivity (avik) Assigned to: Nobody/Anonymous (nobody) Summary: smtplib.SMTP.sendmail() does not provide transparency Initial Comment: If the msg parameter to smtplib.SMTP.sendmail() contains a '\r\n.\r\n', the message will be terminated. This will surprise most users, as smtplib should encapsulate the various protocol details rather than expose them. It's also a potential security hole. If user-supplied data is passed as msg, then the user may be able to inject SMTP commands by placing them after a '\r\n.\r\n'. A workaround is to mutilate msg before passing it to smtplib. ---------------------------------------------------------------------- >Comment By: Avi Kivity (avik) Date: 2006-11-13 01:06 Message: Logged In: YES user_id=539971 deleting. ---------------------------------------------------------------------- Comment By: Avi Kivity (avik) Date: 2006-11-13 01:05 Message: Logged In: YES user_id=539971 Sorry, the report is completely bogus. smtplib already does the necessary quoting. I was getting truncated emails from a subversion commit hook, and jumped to conclusions. Turned out the commit hook was using the sendmail command, NOT smtplib (although it does have that option). Sorry for the noise. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-13 00:07 Message: Logged In: YES user_id=849994 As there were almost no changes in smtplib between 2.4 and 2.5, I think that 2.5 is enough, if someone backports it to 2.4, he can adapt if necessary. ---------------------------------------------------------------------- Comment By: Avi Kivity (avik) Date: 2006-11-13 00:00 Message: Logged In: YES user_id=539971 Yes. Do I need to submit it against 2.4 or 2.5, or both? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 23:56 Message: Logged In: YES user_id=21627 Would you like to contribute a patch to fix this problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595045&group_id=5470 From noreply at sourceforge.net Mon Nov 13 00:52:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 15:52:58 -0800 Subject: [ python-Bugs-1512163 ] mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Message-ID: Bugs item #1512163, was opened at 2006-06-25 16:38 Message generated for change (Comment added) made by baikie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512163&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox (2.5b1): locking doesn't work (esp. on FreeBSD) Initial Comment: fcntl/flock() locking of mailboxes is actually disabled due to a typo: --- mailbox.py.orig +++ mailbox.py @@ -15,7 +15,7 @@ import rfc822 import StringIO try: - import fnctl + import fcntl except ImportError: fcntl = None However, once enabled, it doesn't work on FreeBSD - the lock() method always raises ExternalClashError (tested on 5.3). This is because flock(), lockf() and fcntl locking share the same underlying mechanism on this system (and probably others), and so the second lock can never be acquired. ---------------------------------------------------------------------- >Comment By: David Watson (baikie) Date: 2006-11-12 23:52 Message: Logged In: YES user_id=1504904 I'd forgotten about this for a while, but I see the docs didn't actually get changed for 2.5. I was going to submit a patch for them today and suggest using subclasses as described below, but then I realized that subclassing wouldn't work, since the code makes use of the module functions _lock_file() and _unlock_file() outside of the lock()/unlock() methods. A possible solution is attached; the Mailbox class is given methods _acquire_lock() and _release_lock() wrapping _lock_file() and _unlock_file(), and these are used instead (thus, they can be overridden as methods, but if someone had replaced _lock_file() in the module namespace instead, then their code would still work). Also attached is a minimal doc patch to describe the new (shorter) list of locking methods. I've called the system-call locking "fcntl()" since that's the usual term when dealing with mailboxes, and the name fcntl.lockf() is misleading (it calls fcntl() directly, not lockf(), and the Linux man pages say that "In general, the relation between lockf() and fcntl() is unspecified."). ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-27 04:21 Message: Logged In: YES user_id=33168 Is the optional parameter necessary if you use inheritance (assuming there's a class/object in there)? Maybe it would be better to have a subclass? Would that be better for us to provide or just to add something to the docs that a user could make a subclass to work around locking issues? I haven't looked at the issues, but if we really need an API change, I'm probably ok with it since it would seem to be quite small. If an API change is really required (doc isn't sufficient), I'd like it to go in ASAP. We could doc for 2.5 and if there's a problem fix for 2.6. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-27 00:24 Message: Logged In: YES user_id=11375 Hm, this looks messy; I doubt the module can know if you want lockf() or fcntl() locking. Maybe Mailbox.lock() should grow an optional parameter that lets you specify the locking mechanism to use -- lockf, fcntl, or both. (But defaulting to what?) On the other hand, maybe it's too late to go making API changes for beta2 (but I suspect it would be OK in this case). ---------------------------------------------------------------------- Comment By: David Watson (baikie) Date: 2006-06-26 23:56 Message: Logged In: YES user_id=1504904 Yeah, it works fine now (locks successfully when the mailbox isn't locked by another process, and fails when it is locked), although I was reminded that the Python install process didn't work properly (I've submitted another bug report). However, I should point out that flock() locking is required when working with qmail on (for example) Linux - flock() is the only locking mechanism it uses, and as noted below, flock() on Linux is independent from fcntl/lockf(). ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 14:27 Message: Logged In: YES user_id=11375 Typo fixed in rev. 47099; flock() calls removed in rev. 47100; a test for lock conflicts added in rev. 47101. David, please try out the current SVN head and let me know if matters have improved. I'll wait to see the buildbot reports before closing this bug. (Surprisingly, we don't seem to have a FreeBSD buildbot, though we do have an OpenBSD one that didn't seem to have a problem with the original version of the mailbox code.) ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-06-26 13:56 Message: Logged In: YES user_id=11375 Interesting. The man page for flock() on my Linux system says of flock() in a certain version: "This yields true BSD semantics: there is no interaction between the types of lock placed by flock(2) and fcntl(2), and flock(2) does not detect deadlock." Apparently this is out of date, and placing two locks is harmful. I think it's best to just use one set of locking primitives, and that one should be lockf(); the flock() calls should be removed. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-25 20:52 Message: Logged In: YES user_id=33168 Andrew, are you helping maintain this module? David is correct that fcntl is mispelled in current svn. Not sure what to do about the locking issue. David, would it be possible for you to work on a patch to correct this problem? I'm not sure if any developer has access to a FreeBSD box similar to yours. (There are a couple that use FreeBSD though.) It would be great to come up with tests for this if the current ones don't stress this situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1512163&group_id=5470 From noreply at sourceforge.net Mon Nov 13 03:27:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 18:27:55 -0800 Subject: [ python-Bugs-1595365 ] User-agent header added by an opener is "frozen" Message-ID: Bugs item #1595365, was opened at 2006-11-13 03: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=1595365&group_id=5470 Please note that this 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 Private: No Submitted By: Bj?rn Steinbrink (der_doener) Assigned to: Nobody/Anonymous (nobody) Summary: User-agent header added by an opener is "frozen" Initial Comment: If a Request object gets an User-agent header added by an opener, that header seems to be "frozen". Although header_items() shows the changed header, the request still uses the old one. This does not happen if the header is set before the request is passed to the opener, i.e. when the header is not set automatically, subsequent changes are respected. I'm using Python 2.4.4 from Debian's sid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595365&group_id=5470 From noreply at sourceforge.net Mon Nov 13 12:33:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Nov 2006 03:33:21 -0800 Subject: [ python-Bugs-1593384 ] No IDLE in Windows Message-ID: Bugs item #1593384, was opened at 2006-11-09 15:49 Message generated for change (Comment added) made by a_v_i You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: A_V_I (a_v_i) Assigned to: Nobody/Anonymous (nobody) Summary: No IDLE in Windows Initial Comment: I have installed Python 2.5 on WinXP using python-25.msi with all features included and all default direcories , etc. When I tried to use IDLE I had got the following results: - shortcut in Start -> ... does not do anything - no IDLE in Python25\Tools How can I get IDLE for usage? ---------------------------------------------------------------------- >Comment By: A_V_I (a_v_i) Date: 2006-11-13 14:33 Message: Logged In: YES user_id=1641322 Properties: IDLE (Python GUI) Target Python 2.5 Start in C:\Python25 Shortcut key None Run Normal window ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-09 22:35 Message: Logged In: YES user_id=21627 Can you please report the properties of the IDLE shortcut? (right-button on the start menu item, properties) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 From noreply at sourceforge.net Mon Nov 13 12:33:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Nov 2006 03:33:36 -0800 Subject: [ python-Bugs-1593384 ] No IDLE in Windows Message-ID: Bugs item #1593384, was opened at 2006-11-09 15:49 Message generated for change (Comment added) made by a_v_i You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: A_V_I (a_v_i) Assigned to: Nobody/Anonymous (nobody) Summary: No IDLE in Windows Initial Comment: I have installed Python 2.5 on WinXP using python-25.msi with all features included and all default direcories , etc. When I tried to use IDLE I had got the following results: - shortcut in Start -> ... does not do anything - no IDLE in Python25\Tools How can I get IDLE for usage? ---------------------------------------------------------------------- >Comment By: A_V_I (a_v_i) Date: 2006-11-13 14:33 Message: Logged In: YES user_id=1641322 Properties: IDLE (Python GUI) Target Python 2.5 Start in C:\Python25 Shortcut key None Run Normal window ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-13 14:33 Message: Logged In: YES user_id=1641322 Properties: IDLE (Python GUI) Target Python 2.5 Start in C:\Python25 Shortcut key None Run Normal window ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-09 22:35 Message: Logged In: YES user_id=21627 Can you please report the properties of the IDLE shortcut? (right-button on the start menu item, properties) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 From noreply at sourceforge.net Mon Nov 13 14:00:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Nov 2006 05:00:29 -0800 Subject: [ python-Bugs-1595594 ] parser module bug for nested try...except statements Message-ID: Bugs item #1595594, was opened at 2006-11-13 14: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=1595594&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Kay Schluehr (schluehrk) Assigned to: Nobody/Anonymous (nobody) Summary: parser module bug for nested try...except statements Initial Comment: The following block of source code causes an exception when tried to parse, listify and restoring an ast object: source = """ try: try: TRY_BLOCK except EXC1: EXC_BLOCK1 except EXC2: EXC_BLOCK1 except EXC3: FIN_BLOCK """ import parser stlist = parser.suite(source).tolist() # o.k. parser.sequence2st(stlist) Traceback (most recent call last): File "", line 1, in ? ParserError: Expected node type 297, got -31392. The node value -31392 is at random and not reproducable. The problem does not occur when only one except branch in the inner try is used: source = """ try: try: TRY_BLOCK except EXC1: EXC_BLOCK1 except EXC3: FIN_BLOCK """ import parser stlist = parser.suite(source).tolist() # o.k. parser.sequence2st(stlist) # o.k. It also doesn't occur for an outer finally-clause instead of an except clause. The problem is reproducable for Python 2.5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595594&group_id=5470 From noreply at sourceforge.net Mon Nov 13 14:26:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Nov 2006 05:26:57 -0800 Subject: [ python-Bugs-1595594 ] parser module bug for nested try...except statements Message-ID: Bugs item #1595594, was opened at 2006-11-13 13:00 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595594&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Kay Schluehr (schluehrk) >Assigned to: Georg Brandl (gbrandl) Summary: parser module bug for nested try...except statements Initial Comment: The following block of source code causes an exception when tried to parse, listify and restoring an ast object: source = """ try: try: TRY_BLOCK except EXC1: EXC_BLOCK1 except EXC2: EXC_BLOCK1 except EXC3: FIN_BLOCK """ import parser stlist = parser.suite(source).tolist() # o.k. parser.sequence2st(stlist) Traceback (most recent call last): File "", line 1, in ? ParserError: Expected node type 297, got -31392. The node value -31392 is at random and not reproducable. The problem does not occur when only one except branch in the inner try is used: source = """ try: try: TRY_BLOCK except EXC1: EXC_BLOCK1 except EXC3: FIN_BLOCK """ import parser stlist = parser.suite(source).tolist() # o.k. parser.sequence2st(stlist) # o.k. It also doesn't occur for an outer finally-clause instead of an except clause. The problem is reproducable for Python 2.5 ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-13 13:26 Message: Logged In: YES user_id=849994 I can reproduce this with the 2.5.0 release, but not with the latest 2.5 SVN or the 2.6 SVN. Closing as outdated. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595594&group_id=5470 From noreply at sourceforge.net Mon Nov 13 15:00:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Nov 2006 06:00:21 -0800 Subject: [ python-Bugs-944396 ] urllib2 doesn't handle username/password in url Message-ID: Bugs item #944396, was opened at 2004-04-29 16:34 Message generated for change (Comment added) made by orsenthil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944396&group_id=5470 Please note that this 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: Duplicate Priority: 5 Private: No Submitted By: Chris Withers (fresh) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 doesn't handle username/password in url Initial Comment: >>> urllib2.urlopen('http://username:password at server') Traceback (most recent call last): File "", line 1, in ? File "C:\PYTHON23\lib\urllib2.py", line 129, in urlopen return _opener.open(url, data) File "C:\PYTHON23\lib\urllib2.py", line 326, in open '_open', req) File "C:\PYTHON23\lib\urllib2.py", line 306, in _call_chain result = func(*args) File "C:\PYTHON23\lib\urllib2.py", line 901, in http_open return self.do_open(httplib.HTTP, req) File "C:\PYTHON23\lib\urllib2.py", line 860, in do_open h = http_class(host) # will parse host:port File "C:\Python23\lib\httplib.py", line 1009, in __init__ self._setup(self._connection_class(host, port, strict)) File "C:\Python23\lib\httplib.py", line 507, in __init__ self._set_hostport(host, port) File "C:\Python23\lib\httplib.py", line 518, in _set_hostport raise InvalidURL("nonnumeric port: '%s'" % host[i+1:]) httplib.InvalidURL: nonnumeric port: 'password at server' cheers, Chris ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2006-11-13 19:30 Message: Logged In: YES user_id=942711 It does handle: proxy_user = 'user_name' proxy_password ='password' # Setup the Proxy with urllib2 proxy_url = 'http://' + proxy_user + ':' + proxy_password + '@' + PROXY_IP proxy_support = urllib2.ProxyHandler({"http":proxy_url}) opener = urllib2.build_opener(proxy_support,urllib2.HTTPHandler) urllib2.install_opener(opener) Worked properly for me so long. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-02-21 02:30 Message: Logged In: YES user_id=849994 This is also reported by #979407. ---------------------------------------------------------------------- Comment By: Sjoerd Mullender (sjoerd) Date: 2004-05-06 02:52 Message: Logged In: YES user_id=43607 I don't know (nor care) about RFC 1738, but it's successor RFC 2396 *does* mention @: as a possible "server". See section 3.2.2. I admit, it also says that it is not recommended, but it does specifically allow username + password in the URI. ---------------------------------------------------------------------- Comment By: Chris Withers (fresh) Date: 2004-05-06 02:31 Message: Logged In: YES user_id=24723 However, given that the original urllib supported this, it is suprising that urllib2 doesn't. ---------------------------------------------------------------------- Comment By: Andrew Langmead (langmead) Date: 2004-05-06 02:04 Message: Logged In: YES user_id=119306 Although allowing a username and password in the URL is a common client extension, it is not part of the standard ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=944396&group_id=5470 From noreply at sourceforge.net Mon Nov 13 17:54:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Nov 2006 08:54:23 -0800 Subject: [ python-Bugs-1595742 ] SocketServer allow_reuse_address checked in constructor Message-ID: Bugs item #1595742, was opened at 2006-11-13 11:54 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595742&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Peter Parente (parente) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer allow_reuse_address checked in constructor Initial Comment: Python 2.4.3 (#1, Oct 1 2006, 18:00:19) [GCC 4.1.1 20060928 (Red Hat 4.1.1-28)] on linux2 The documentation in the SocketServer class indicates that the allow_reuse_address flag may be set on a SocketServer subclass *or instance.* However, the flag is read in a call to the server_bind() from the constructor of the server object. Therefore, setting the flag on a created instance has no effect. This is problematic when trying to set the flag on SimpleXMLRPCServer instances, for instance, which are often not subclassed. This flag should probably become one of the keyword arguments in the constructor of a SocketServer object. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595742&group_id=5470 From noreply at sourceforge.net Mon Nov 13 19:16:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Nov 2006 10:16:57 -0800 Subject: [ python-Bugs-1593384 ] No IDLE in Windows Message-ID: Bugs item #1593384, was opened at 2006-11-09 13:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: A_V_I (a_v_i) Assigned to: Nobody/Anonymous (nobody) Summary: No IDLE in Windows Initial Comment: I have installed Python 2.5 on WinXP using python-25.msi with all features included and all default direcories , etc. When I tried to use IDLE I had got the following results: - shortcut in Start -> ... does not do anything - no IDLE in Python25\Tools How can I get IDLE for usage? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-13 19:16 Message: Logged In: YES user_id=21627 I see. Can you please run C:\Python25\python.exe C:\Python25\Lib\idlelib\idle.pyw in a cmd.exe window and report what happens? ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-13 12:33 Message: Logged In: YES user_id=1641322 Properties: IDLE (Python GUI) Target Python 2.5 Start in C:\Python25 Shortcut key None Run Normal window ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-13 12:33 Message: Logged In: YES user_id=1641322 Properties: IDLE (Python GUI) Target Python 2.5 Start in C:\Python25 Shortcut key None Run Normal window ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-09 20:35 Message: Logged In: YES user_id=21627 Can you please report the properties of the IDLE shortcut? (right-button on the start menu item, properties) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 From noreply at sourceforge.net Mon Nov 13 20:17:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Nov 2006 11:17:26 -0800 Subject: [ python-Bugs-1595822 ] read() in windows stops on chr(26) Message-ID: Bugs item #1595822, was opened at 2006-11-13 12: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=1595822&group_id=5470 Please note that this 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 Private: No Submitted By: reson5 (reson5) Assigned to: Nobody/Anonymous (nobody) Summary: read() in windows stops on chr(26) Initial Comment: >From standard distribution (installation through .exe file): open() function in Windows (I have win2k and xp) opens files in text mode and stops on chr(26). I cannot parse a binary file (!). On Linux all works fine. Regards, Reson5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595822&group_id=5470 From noreply at sourceforge.net Mon Nov 13 20:20:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Nov 2006 11:20:38 -0800 Subject: [ python-Bugs-1595822 ] read() in windows stops on chr(26) Message-ID: Bugs item #1595822, was opened at 2006-11-13 12:17 Message generated for change (Comment added) made by reson5 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595822&group_id=5470 Please note that this 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 Private: No Submitted By: reson5 (reson5) Assigned to: Nobody/Anonymous (nobody) Summary: read() in windows stops on chr(26) Initial Comment: >From standard distribution (installation through .exe file): open() function in Windows (I have win2k and xp) opens files in text mode and stops on chr(26). I cannot parse a binary file (!). On Linux all works fine. Regards, Reson5 ---------------------------------------------------------------------- >Comment By: reson5 (reson5) Date: 2006-11-13 12:20 Message: Logged In: YES user_id=1355850 To clarify, The behavior is not uniform on Linux it opens in binary and on windows in text (!) Regards, Reson5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595822&group_id=5470 From noreply at sourceforge.net Mon Nov 13 20:29:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Nov 2006 11:29:07 -0800 Subject: [ python-Bugs-1595822 ] read() in windows stops on chr(26) Message-ID: Bugs item #1595822, was opened at 2006-11-13 19:17 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595822&group_id=5470 Please note that this 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: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: reson5 (reson5) Assigned to: Nobody/Anonymous (nobody) Summary: read() in windows stops on chr(26) Initial Comment: >From standard distribution (installation through .exe file): open() function in Windows (I have win2k and xp) opens files in text mode and stops on chr(26). I cannot parse a binary file (!). On Linux all works fine. Regards, Reson5 ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-13 19:29 Message: Logged In: YES user_id=849994 chr(26) or Ctrl+Z is the end-of-file character in Windows, for text-mode files. If you open the file in binary mode, e.g. with open("filename", "rb"), there should be no problems with reading the chr(26). ---------------------------------------------------------------------- Comment By: reson5 (reson5) Date: 2006-11-13 19:20 Message: Logged In: YES user_id=1355850 To clarify, The behavior is not uniform on Linux it opens in binary and on windows in text (!) Regards, Reson5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595822&group_id=5470 From noreply at sourceforge.net Tue Nov 14 06:59:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Nov 2006 21:59:12 -0800 Subject: [ python-Bugs-1593384 ] No IDLE in Windows Message-ID: Bugs item #1593384, was opened at 2006-11-09 15:49 Message generated for change (Comment added) made by a_v_i You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: A_V_I (a_v_i) Assigned to: Nobody/Anonymous (nobody) Summary: No IDLE in Windows Initial Comment: I have installed Python 2.5 on WinXP using python-25.msi with all features included and all default direcories , etc. When I tried to use IDLE I had got the following results: - shortcut in Start -> ... does not do anything - no IDLE in Python25\Tools How can I get IDLE for usage? ---------------------------------------------------------------------- >Comment By: A_V_I (a_v_i) Date: 2006-11-14 08:59 Message: Logged In: YES user_id=1641322 Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\Administrator>C:\Python25\python.exe C:\Python25\Lib\i dlelib\idle.pyw Traceback (most recent call last): File "C:\Python25\Lib\idlelib\idle.pyw", line 21, in idlelib.PyShell.main() File "C:\Python25\lib\idlelib\PyShell.py", line 1388, in main root = Tk(className="Idle") File "C:\Python25\lib\lib-tk\Tkinter.py", line 1636, in __init__ self.tk = _tkinter.create(screenName, baseName, className, interactive, want objects, useTk, sync, use) _tkinter.TclError: Can't find a usable init.tcl in the following directories: {C:\IBMTOOLS\Python22\tcl\tcl8.4} {C:\IBMTOOLS\Python22\tcl\tcl8.4} C:/IBMTO OLS/Python22/tcl/tcl8.4 C:/Python25/lib/tcl8.4 C:/lib/tcl8.4 C:/library This probably means that Tcl wasn't installed properly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-13 21:16 Message: Logged In: YES user_id=21627 I see. Can you please run C:\Python25\python.exe C:\Python25\Lib\idlelib\idle.pyw in a cmd.exe window and report what happens? ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-13 14:33 Message: Logged In: YES user_id=1641322 Properties: IDLE (Python GUI) Target Python 2.5 Start in C:\Python25 Shortcut key None Run Normal window ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-13 14:33 Message: Logged In: YES user_id=1641322 Properties: IDLE (Python GUI) Target Python 2.5 Start in C:\Python25 Shortcut key None Run Normal window ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-09 22:35 Message: Logged In: YES user_id=21627 Can you please report the properties of the IDLE shortcut? (right-button on the start menu item, properties) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 From noreply at sourceforge.net Tue Nov 14 07:16:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 13 Nov 2006 22:16:27 -0800 Subject: [ python-Bugs-1593384 ] No IDLE in Windows Message-ID: Bugs item #1593384, was opened at 2006-11-09 13:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: A_V_I (a_v_i) Assigned to: Nobody/Anonymous (nobody) Summary: No IDLE in Windows Initial Comment: I have installed Python 2.5 on WinXP using python-25.msi with all features included and all default direcories , etc. When I tried to use IDLE I had got the following results: - shortcut in Start -> ... does not do anything - no IDLE in Python25\Tools How can I get IDLE for usage? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-14 07:16 Message: Logged In: YES user_id=21627 Can you please check whether you have TCL_LIBRARY or TK_LIBRARY set in your environment, and, if so, try removing them? ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-14 06:59 Message: Logged In: YES user_id=1641322 Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\Administrator>C:\Python25\python.exe C:\Python25\Lib\i dlelib\idle.pyw Traceback (most recent call last): File "C:\Python25\Lib\idlelib\idle.pyw", line 21, in idlelib.PyShell.main() File "C:\Python25\lib\idlelib\PyShell.py", line 1388, in main root = Tk(className="Idle") File "C:\Python25\lib\lib-tk\Tkinter.py", line 1636, in __init__ self.tk = _tkinter.create(screenName, baseName, className, interactive, want objects, useTk, sync, use) _tkinter.TclError: Can't find a usable init.tcl in the following directories: {C:\IBMTOOLS\Python22\tcl\tcl8.4} {C:\IBMTOOLS\Python22\tcl\tcl8.4} C:/IBMTO OLS/Python22/tcl/tcl8.4 C:/Python25/lib/tcl8.4 C:/lib/tcl8.4 C:/library This probably means that Tcl wasn't installed properly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-13 19:16 Message: Logged In: YES user_id=21627 I see. Can you please run C:\Python25\python.exe C:\Python25\Lib\idlelib\idle.pyw in a cmd.exe window and report what happens? ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-13 12:33 Message: Logged In: YES user_id=1641322 Properties: IDLE (Python GUI) Target Python 2.5 Start in C:\Python25 Shortcut key None Run Normal window ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-13 12:33 Message: Logged In: YES user_id=1641322 Properties: IDLE (Python GUI) Target Python 2.5 Start in C:\Python25 Shortcut key None Run Normal window ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-09 20:35 Message: Logged In: YES user_id=21627 Can you please report the properties of the IDLE shortcut? (right-button on the start menu item, properties) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 From noreply at sourceforge.net Tue Nov 14 10:53:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Nov 2006 01:53:07 -0800 Subject: [ python-Bugs-1593384 ] No IDLE in Windows Message-ID: Bugs item #1593384, was opened at 2006-11-09 15:49 Message generated for change (Comment added) made by a_v_i You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: A_V_I (a_v_i) Assigned to: Nobody/Anonymous (nobody) Summary: No IDLE in Windows Initial Comment: I have installed Python 2.5 on WinXP using python-25.msi with all features included and all default direcories , etc. When I tried to use IDLE I had got the following results: - shortcut in Start -> ... does not do anything - no IDLE in Python25\Tools How can I get IDLE for usage? ---------------------------------------------------------------------- >Comment By: A_V_I (a_v_i) Date: 2006-11-14 12:53 Message: Logged In: YES user_id=1641322 I have got both. When i remove c:\Python25\tcl the response is the same as before If in addition to that I remove c:\Python25\Lib\lib-tk it tells me that I do not have TCL/TK properly configured or it is not in the system ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-14 09:16 Message: Logged In: YES user_id=21627 Can you please check whether you have TCL_LIBRARY or TK_LIBRARY set in your environment, and, if so, try removing them? ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-14 08:59 Message: Logged In: YES user_id=1641322 Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\Administrator>C:\Python25\python.exe C:\Python25\Lib\i dlelib\idle.pyw Traceback (most recent call last): File "C:\Python25\Lib\idlelib\idle.pyw", line 21, in idlelib.PyShell.main() File "C:\Python25\lib\idlelib\PyShell.py", line 1388, in main root = Tk(className="Idle") File "C:\Python25\lib\lib-tk\Tkinter.py", line 1636, in __init__ self.tk = _tkinter.create(screenName, baseName, className, interactive, want objects, useTk, sync, use) _tkinter.TclError: Can't find a usable init.tcl in the following directories: {C:\IBMTOOLS\Python22\tcl\tcl8.4} {C:\IBMTOOLS\Python22\tcl\tcl8.4} C:/IBMTO OLS/Python22/tcl/tcl8.4 C:/Python25/lib/tcl8.4 C:/lib/tcl8.4 C:/library This probably means that Tcl wasn't installed properly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-13 21:16 Message: Logged In: YES user_id=21627 I see. Can you please run C:\Python25\python.exe C:\Python25\Lib\idlelib\idle.pyw in a cmd.exe window and report what happens? ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-13 14:33 Message: Logged In: YES user_id=1641322 Properties: IDLE (Python GUI) Target Python 2.5 Start in C:\Python25 Shortcut key None Run Normal window ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-13 14:33 Message: Logged In: YES user_id=1641322 Properties: IDLE (Python GUI) Target Python 2.5 Start in C:\Python25 Shortcut key None Run Normal window ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-09 22:35 Message: Logged In: YES user_id=21627 Can you please report the properties of the IDLE shortcut? (right-button on the start menu item, properties) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 From noreply at sourceforge.net Tue Nov 14 15:02:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Nov 2006 06:02:45 -0800 Subject: [ python-Bugs-1596321 ] KeyError at exit after 'import threading' in other thread Message-ID: Bugs item #1596321, was opened at 2006-11-14 15: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=1596321&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Walther (cwalther) Assigned to: Nobody/Anonymous (nobody) Summary: KeyError at exit after 'import threading' in other thread Initial Comment: Python 2.4.3 on Windows 2000, though the code in question seems unchanged in current SVN (r46919). I'm using Python embedded in a multithreaded C++ application. When 'import threading' is first done in some Python script that runs in thread A, I get the following exception when a different thread B calls Py_Finalize(): Error in atexit._run_exitfuncs: Traceback (most recent call last): File "C:\Python24\lib\atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "C:\Python24\lib\threading.py", line 636, in __exitfunc self._Thread__delete() File "C:\Python24\lib\threading.py", line 522, in __delete del _active[_get_ident()] KeyError: 680 Error in sys.exitfunc: Traceback (most recent call last): File "C:\Python24\lib\atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "C:\Python24\lib\threading.py", line 636, in __exitfunc self._Thread__delete() File "C:\Python24\lib\threading.py", line 522, in __delete del _active[_get_ident()] KeyError: 680 The reason seems to be that the threading module uses the thread ID of the calling thread as a key to store its _MainThread instance on initialization, and again the thread ID of the calling thread to delete it in its exit function. If these two threads are not the same, the described KeyError occurs. I didn't study this in all detail, but it seems to me that threading.Thread.__delete() does the wrong thing. By doing 'del _active[_get_ident()]', it removes the instance for the calling thread from the _active dictionary. What it should be doing is removing *self* from that dictionary. Is that correct? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1596321&group_id=5470 From noreply at sourceforge.net Tue Nov 14 16:55:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Nov 2006 07:55:46 -0800 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-22 20:07 Message generated for change (Comment added) made by memotype You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 Please note that this 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 Private: No Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 10:55 Message: Logged In: YES user_id=1645242 What is the status on this bug? I tried the work around, but patch doesn't like the diff file provided, says "Processing... I cannot find a patch in there anywhere." ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:55 Message: Logged In: YES user_id=129055 Build finished running; full log attached as python-2.5- ctypes.log.gz. Relevent lines are: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep [... more ld errors ...] collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 And at this point gmake exits and the build stops. Running gmake again just causes the same error to pop up. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:29 Message: Logged In: YES user_id=129055 Ah, well there is a bug then... setup.py does not continue on its own. I've added an attachement of a successful full build log (built with the noctypes patch), and will attach a second full build log that shows the build failing on the error when it finishes running in 10-20 minutes... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 08:14 Message: Logged In: YES user_id=21627 No; setup.py should continue on its own. If it doesn't, that's a bug. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:06 Message: Logged In: YES user_id=129055 loewis: No, the ctypes error messages cause the build to fail. Are you saying to use "gmake -k" or something like that? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 07:15 Message: Logged In: YES user_id=21627 You don't need to disable it. It will print error messages, but you can just ignore them if you don't need the ctypes module. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 23:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 22:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 20:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Tue Nov 14 18:05:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Nov 2006 09:05:44 -0800 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-23 02:07 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 Please note that this 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 Private: No Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-11-14 18:05 Message: Logged In: YES user_id=11105 Well, there is certainly a diff in noctypes.diff. If your patch program cannot handle it, you may want to apply it manually (basically you have to remove/comment out two sections of code in setup.py). It seems that there are actually two bugs: 1. setup.py doesn't continue after trying to import the _ctypes extension. No idea why, but somewhere something exists the process. 2. _ctypes.so does not build (or better fails to load) because of missing symbols: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN I have no access to an AIX system, do I cannot try this out myself. One thing that comes to mind: These functions are implemented in the file Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c. This file is compiled, without errors. One problem could be that the whole file contents are included in an #ifdef block like this: #ifdef __ppc__ ... #endif Can it be that __ppc__ is not defined on this system? Can someone try out to build with these two lines removed? Thanks. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 16:55 Message: Logged In: YES user_id=1645242 What is the status on this bug? I tried the work around, but patch doesn't like the diff file provided, says "Processing... I cannot find a patch in there anywhere." ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:55 Message: Logged In: YES user_id=129055 Build finished running; full log attached as python-2.5- ctypes.log.gz. Relevent lines are: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep [... more ld errors ...] collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 And at this point gmake exits and the build stops. Running gmake again just causes the same error to pop up. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:29 Message: Logged In: YES user_id=129055 Ah, well there is a bug then... setup.py does not continue on its own. I've added an attachement of a successful full build log (built with the noctypes patch), and will attach a second full build log that shows the build failing on the error when it finishes running in 10-20 minutes... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 14:14 Message: Logged In: YES user_id=21627 No; setup.py should continue on its own. If it doesn't, that's a bug. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:06 Message: Logged In: YES user_id=129055 loewis: No, the ctypes error messages cause the build to fail. Are you saying to use "gmake -k" or something like that? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 13:15 Message: Logged In: YES user_id=21627 You don't need to disable it. It will print error messages, but you can just ignore them if you don't need the ctypes module. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 05:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 04:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 02:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Tue Nov 14 19:28:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Nov 2006 10:28:02 -0800 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-22 20:07 Message generated for change (Comment added) made by memotype You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 Please note that this 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 Private: No Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 13:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 12:05 Message: Logged In: YES user_id=11105 Well, there is certainly a diff in noctypes.diff. If your patch program cannot handle it, you may want to apply it manually (basically you have to remove/comment out two sections of code in setup.py). It seems that there are actually two bugs: 1. setup.py doesn't continue after trying to import the _ctypes extension. No idea why, but somewhere something exists the process. 2. _ctypes.so does not build (or better fails to load) because of missing symbols: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN I have no access to an AIX system, do I cannot try this out myself. One thing that comes to mind: These functions are implemented in the file Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c. This file is compiled, without errors. One problem could be that the whole file contents are included in an #ifdef block like this: #ifdef __ppc__ ... #endif Can it be that __ppc__ is not defined on this system? Can someone try out to build with these two lines removed? Thanks. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 10:55 Message: Logged In: YES user_id=1645242 What is the status on this bug? I tried the work around, but patch doesn't like the diff file provided, says "Processing... I cannot find a patch in there anywhere." ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:55 Message: Logged In: YES user_id=129055 Build finished running; full log attached as python-2.5- ctypes.log.gz. Relevent lines are: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep [... more ld errors ...] collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 And at this point gmake exits and the build stops. Running gmake again just causes the same error to pop up. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:29 Message: Logged In: YES user_id=129055 Ah, well there is a bug then... setup.py does not continue on its own. I've added an attachement of a successful full build log (built with the noctypes patch), and will attach a second full build log that shows the build failing on the error when it finishes running in 10-20 minutes... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 08:14 Message: Logged In: YES user_id=21627 No; setup.py should continue on its own. If it doesn't, that's a bug. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:06 Message: Logged In: YES user_id=129055 loewis: No, the ctypes error messages cause the build to fail. Are you saying to use "gmake -k" or something like that? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 07:15 Message: Logged In: YES user_id=21627 You don't need to disable it. It will print error messages, but you can just ignore them if you don't need the ctypes module. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 23:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 22:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 20:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Tue Nov 14 19:28:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Nov 2006 10:28:32 -0800 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-22 20:07 Message generated for change (Comment added) made by memotype You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 Please note that this 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 Private: No Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 13:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 13:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 12:05 Message: Logged In: YES user_id=11105 Well, there is certainly a diff in noctypes.diff. If your patch program cannot handle it, you may want to apply it manually (basically you have to remove/comment out two sections of code in setup.py). It seems that there are actually two bugs: 1. setup.py doesn't continue after trying to import the _ctypes extension. No idea why, but somewhere something exists the process. 2. _ctypes.so does not build (or better fails to load) because of missing symbols: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN I have no access to an AIX system, do I cannot try this out myself. One thing that comes to mind: These functions are implemented in the file Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c. This file is compiled, without errors. One problem could be that the whole file contents are included in an #ifdef block like this: #ifdef __ppc__ ... #endif Can it be that __ppc__ is not defined on this system? Can someone try out to build with these two lines removed? Thanks. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 10:55 Message: Logged In: YES user_id=1645242 What is the status on this bug? I tried the work around, but patch doesn't like the diff file provided, says "Processing... I cannot find a patch in there anywhere." ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:55 Message: Logged In: YES user_id=129055 Build finished running; full log attached as python-2.5- ctypes.log.gz. Relevent lines are: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep [... more ld errors ...] collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 And at this point gmake exits and the build stops. Running gmake again just causes the same error to pop up. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:29 Message: Logged In: YES user_id=129055 Ah, well there is a bug then... setup.py does not continue on its own. I've added an attachement of a successful full build log (built with the noctypes patch), and will attach a second full build log that shows the build failing on the error when it finishes running in 10-20 minutes... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 08:14 Message: Logged In: YES user_id=21627 No; setup.py should continue on its own. If it doesn't, that's a bug. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:06 Message: Logged In: YES user_id=129055 loewis: No, the ctypes error messages cause the build to fail. Are you saying to use "gmake -k" or something like that? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 07:15 Message: Logged In: YES user_id=21627 You don't need to disable it. It will print error messages, but you can just ignore them if you don't need the ctypes module. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 23:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 22:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 20:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Tue Nov 14 19:35:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Nov 2006 10:35:21 -0800 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-22 20:07 Message generated for change (Comment added) made by memotype You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 Please note that this 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 Private: No Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 13:35 Message: Logged In: YES user_id=1645242 Originator: NO _AIX however, /is/ defined, so maybe s/__aix__/_AIX/g? ~/Python-2.5 $ cat <<. > test.c > int main() { > #ifdef _AIX > return 0; > #endif > #ifndef _AIX > return 1; > #endif > } > . ~/Python-2.5 $ gcc -o test test.c ~/Python-2.5 $ ./test ~/Python-2.5 $ echo $? 0 ~/Python-2.5 $ ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 13:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 13:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 12:05 Message: Logged In: YES user_id=11105 Well, there is certainly a diff in noctypes.diff. If your patch program cannot handle it, you may want to apply it manually (basically you have to remove/comment out two sections of code in setup.py). It seems that there are actually two bugs: 1. setup.py doesn't continue after trying to import the _ctypes extension. No idea why, but somewhere something exists the process. 2. _ctypes.so does not build (or better fails to load) because of missing symbols: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN I have no access to an AIX system, do I cannot try this out myself. One thing that comes to mind: These functions are implemented in the file Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c. This file is compiled, without errors. One problem could be that the whole file contents are included in an #ifdef block like this: #ifdef __ppc__ ... #endif Can it be that __ppc__ is not defined on this system? Can someone try out to build with these two lines removed? Thanks. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 10:55 Message: Logged In: YES user_id=1645242 What is the status on this bug? I tried the work around, but patch doesn't like the diff file provided, says "Processing... I cannot find a patch in there anywhere." ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:55 Message: Logged In: YES user_id=129055 Build finished running; full log attached as python-2.5- ctypes.log.gz. Relevent lines are: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep [... more ld errors ...] collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 And at this point gmake exits and the build stops. Running gmake again just causes the same error to pop up. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:29 Message: Logged In: YES user_id=129055 Ah, well there is a bug then... setup.py does not continue on its own. I've added an attachement of a successful full build log (built with the noctypes patch), and will attach a second full build log that shows the build failing on the error when it finishes running in 10-20 minutes... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 08:14 Message: Logged In: YES user_id=21627 No; setup.py should continue on its own. If it doesn't, that's a bug. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:06 Message: Logged In: YES user_id=129055 loewis: No, the ctypes error messages cause the build to fail. Are you saying to use "gmake -k" or something like that? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 07:15 Message: Logged In: YES user_id=21627 You don't need to disable it. It will print error messages, but you can just ignore them if you don't need the ctypes module. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 23:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 22:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 20:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Tue Nov 14 19:39:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Nov 2006 10:39:23 -0800 Subject: [ python-Bugs-1593384 ] No IDLE in Windows Message-ID: Bugs item #1593384, was opened at 2006-11-09 13:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: A_V_I (a_v_i) Assigned to: Nobody/Anonymous (nobody) Summary: No IDLE in Windows Initial Comment: I have installed Python 2.5 on WinXP using python-25.msi with all features included and all default direcories , etc. When I tried to use IDLE I had got the following results: - shortcut in Start -> ... does not do anything - no IDLE in Python25\Tools How can I get IDLE for usage? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-14 19:39 Message: Logged In: YES user_id=21627 Originator: NO I wasn't asking that you remove the files: I asked that you remove (unset) the environment variables. ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-14 10:53 Message: Logged In: YES user_id=1641322 I have got both. When i remove c:\Python25\tcl the response is the same as before If in addition to that I remove c:\Python25\Lib\lib-tk it tells me that I do not have TCL/TK properly configured or it is not in the system ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-14 07:16 Message: Logged In: YES user_id=21627 Can you please check whether you have TCL_LIBRARY or TK_LIBRARY set in your environment, and, if so, try removing them? ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-14 06:59 Message: Logged In: YES user_id=1641322 Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\Administrator>C:\Python25\python.exe C:\Python25\Lib\i dlelib\idle.pyw Traceback (most recent call last): File "C:\Python25\Lib\idlelib\idle.pyw", line 21, in idlelib.PyShell.main() File "C:\Python25\lib\idlelib\PyShell.py", line 1388, in main root = Tk(className="Idle") File "C:\Python25\lib\lib-tk\Tkinter.py", line 1636, in __init__ self.tk = _tkinter.create(screenName, baseName, className, interactive, want objects, useTk, sync, use) _tkinter.TclError: Can't find a usable init.tcl in the following directories: {C:\IBMTOOLS\Python22\tcl\tcl8.4} {C:\IBMTOOLS\Python22\tcl\tcl8.4} C:/IBMTO OLS/Python22/tcl/tcl8.4 C:/Python25/lib/tcl8.4 C:/lib/tcl8.4 C:/library This probably means that Tcl wasn't installed properly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-13 19:16 Message: Logged In: YES user_id=21627 I see. Can you please run C:\Python25\python.exe C:\Python25\Lib\idlelib\idle.pyw in a cmd.exe window and report what happens? ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-13 12:33 Message: Logged In: YES user_id=1641322 Properties: IDLE (Python GUI) Target Python 2.5 Start in C:\Python25 Shortcut key None Run Normal window ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-13 12:33 Message: Logged In: YES user_id=1641322 Properties: IDLE (Python GUI) Target Python 2.5 Start in C:\Python25 Shortcut key None Run Normal window ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-09 20:35 Message: Logged In: YES user_id=21627 Can you please report the properties of the IDLE shortcut? (right-button on the start menu item, properties) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 From noreply at sourceforge.net Tue Nov 14 19:47:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Nov 2006 10:47:16 -0800 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-23 02:07 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 Please note that this 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 Private: No Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-11-14 19:47 Message: Logged In: YES user_id=11105 Originator: NO Hm, I was asking for '__ppc__', not '__aix__'. Can you look for processor specific defines, please? ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 19:35 Message: Logged In: YES user_id=1645242 Originator: NO _AIX however, /is/ defined, so maybe s/__aix__/_AIX/g? ~/Python-2.5 $ cat <<. > test.c > int main() { > #ifdef _AIX > return 0; > #endif > #ifndef _AIX > return 1; > #endif > } > . ~/Python-2.5 $ gcc -o test test.c ~/Python-2.5 $ ./test ~/Python-2.5 $ echo $? 0 ~/Python-2.5 $ ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 19:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 19:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 18:05 Message: Logged In: YES user_id=11105 Well, there is certainly a diff in noctypes.diff. If your patch program cannot handle it, you may want to apply it manually (basically you have to remove/comment out two sections of code in setup.py). It seems that there are actually two bugs: 1. setup.py doesn't continue after trying to import the _ctypes extension. No idea why, but somewhere something exists the process. 2. _ctypes.so does not build (or better fails to load) because of missing symbols: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN I have no access to an AIX system, do I cannot try this out myself. One thing that comes to mind: These functions are implemented in the file Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c. This file is compiled, without errors. One problem could be that the whole file contents are included in an #ifdef block like this: #ifdef __ppc__ ... #endif Can it be that __ppc__ is not defined on this system? Can someone try out to build with these two lines removed? Thanks. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 16:55 Message: Logged In: YES user_id=1645242 What is the status on this bug? I tried the work around, but patch doesn't like the diff file provided, says "Processing... I cannot find a patch in there anywhere." ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:55 Message: Logged In: YES user_id=129055 Build finished running; full log attached as python-2.5- ctypes.log.gz. Relevent lines are: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep [... more ld errors ...] collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 And at this point gmake exits and the build stops. Running gmake again just causes the same error to pop up. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:29 Message: Logged In: YES user_id=129055 Ah, well there is a bug then... setup.py does not continue on its own. I've added an attachement of a successful full build log (built with the noctypes patch), and will attach a second full build log that shows the build failing on the error when it finishes running in 10-20 minutes... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 14:14 Message: Logged In: YES user_id=21627 No; setup.py should continue on its own. If it doesn't, that's a bug. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:06 Message: Logged In: YES user_id=129055 loewis: No, the ctypes error messages cause the build to fail. Are you saying to use "gmake -k" or something like that? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 13:15 Message: Logged In: YES user_id=21627 You don't need to disable it. It will print error messages, but you can just ignore them if you don't need the ctypes module. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 05:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 04:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 02:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Tue Nov 14 20:08:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Nov 2006 11:08:49 -0800 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-23 02:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 Please note that this 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 Private: No Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-14 20:08 Message: Logged In: YES user_id=21627 Originator: NO Please compile an empty file with "gcc -E -dD empty.c" to find out what defines are builtin. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 19:47 Message: Logged In: YES user_id=11105 Originator: NO Hm, I was asking for '__ppc__', not '__aix__'. Can you look for processor specific defines, please? ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 19:35 Message: Logged In: YES user_id=1645242 Originator: NO _AIX however, /is/ defined, so maybe s/__aix__/_AIX/g? ~/Python-2.5 $ cat <<. > test.c > int main() { > #ifdef _AIX > return 0; > #endif > #ifndef _AIX > return 1; > #endif > } > . ~/Python-2.5 $ gcc -o test test.c ~/Python-2.5 $ ./test ~/Python-2.5 $ echo $? 0 ~/Python-2.5 $ ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 19:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 19:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 18:05 Message: Logged In: YES user_id=11105 Well, there is certainly a diff in noctypes.diff. If your patch program cannot handle it, you may want to apply it manually (basically you have to remove/comment out two sections of code in setup.py). It seems that there are actually two bugs: 1. setup.py doesn't continue after trying to import the _ctypes extension. No idea why, but somewhere something exists the process. 2. _ctypes.so does not build (or better fails to load) because of missing symbols: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN I have no access to an AIX system, do I cannot try this out myself. One thing that comes to mind: These functions are implemented in the file Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c. This file is compiled, without errors. One problem could be that the whole file contents are included in an #ifdef block like this: #ifdef __ppc__ ... #endif Can it be that __ppc__ is not defined on this system? Can someone try out to build with these two lines removed? Thanks. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 16:55 Message: Logged In: YES user_id=1645242 What is the status on this bug? I tried the work around, but patch doesn't like the diff file provided, says "Processing... I cannot find a patch in there anywhere." ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:55 Message: Logged In: YES user_id=129055 Build finished running; full log attached as python-2.5- ctypes.log.gz. Relevent lines are: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep [... more ld errors ...] collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 And at this point gmake exits and the build stops. Running gmake again just causes the same error to pop up. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:29 Message: Logged In: YES user_id=129055 Ah, well there is a bug then... setup.py does not continue on its own. I've added an attachement of a successful full build log (built with the noctypes patch), and will attach a second full build log that shows the build failing on the error when it finishes running in 10-20 minutes... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 14:14 Message: Logged In: YES user_id=21627 No; setup.py should continue on its own. If it doesn't, that's a bug. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:06 Message: Logged In: YES user_id=129055 loewis: No, the ctypes error messages cause the build to fail. Are you saying to use "gmake -k" or something like that? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 13:15 Message: Logged In: YES user_id=21627 You don't need to disable it. It will print error messages, but you can just ignore them if you don't need the ctypes module. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 05:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 04:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 02:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Tue Nov 14 20:25:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Nov 2006 11:25:14 -0800 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-22 20:07 Message generated for change (Comment added) made by memotype You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 Please note that this 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 Private: No Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 14:25 Message: Logged In: YES user_id=1645242 Originator: NO I'm sorry, I meant __ppc__, it was the __ppc__ lines that I removed. As for PPC specific defines, I can't find any that work, but grepping around in /usr/include shows: /usr/include $ grep -i powerpc * aouthdr.h: * Defines for the POWER and PowerPC CPU Types aouthdr.h:#define TCPU_PPC 1 /* PowerPC common architecture 32 bit mode */ aouthdr.h:#define TCPU_PPC64 2 /* PowerPC common architecture 64 bit mode */ aouthdr.h:#define TCPU_COM 3 /* POWER and PowerPC architecture common */ aouthdr.h: /* and PowerPC architecture implementations */ aouthdr.h:#define TCPU_601 6 /* 601 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_603 7 /* 603 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_604 8 /* 604 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_620 16 /* 620 implementation of PowerPC 64-bit architecture */ aouthdr.h:#define TCPU_A35 17 /* A35 implementation of PowerPC 64-bit architecture */ filehdr.h:/* IBM POWER and PowerPC */ frs.h:| - rom_scan_R2_6002_block_t (PowerPC devices) frs.h:| - rom_scan_R2_6003_block_t (60x PowerPC devices) frs.h:| The PowerPC 601 Bus has such characteristics. frs.h:| that matches the PowerPC 60X Bus and PowerPC System Architecture frs_60x.h: | as defined by PowerPC System ARch and unique frs_60x.h:| PowerPC Feature/VPD Header reloc.h: * POWER and PowerPC - relocation types I would love to send you a copy of the aouthdr.h, but I'm not sure if that would violate any licenses, so I will have to leave the rest to you guys to look for some definitive documentation as to how to detect ppc from defines. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-14 14:08 Message: Logged In: YES user_id=21627 Originator: NO Please compile an empty file with "gcc -E -dD empty.c" to find out what defines are builtin. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 13:47 Message: Logged In: YES user_id=11105 Originator: NO Hm, I was asking for '__ppc__', not '__aix__'. Can you look for processor specific defines, please? ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 13:35 Message: Logged In: YES user_id=1645242 Originator: NO _AIX however, /is/ defined, so maybe s/__aix__/_AIX/g? ~/Python-2.5 $ cat <<. > test.c > int main() { > #ifdef _AIX > return 0; > #endif > #ifndef _AIX > return 1; > #endif > } > . ~/Python-2.5 $ gcc -o test test.c ~/Python-2.5 $ ./test ~/Python-2.5 $ echo $? 0 ~/Python-2.5 $ ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 13:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 13:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 12:05 Message: Logged In: YES user_id=11105 Well, there is certainly a diff in noctypes.diff. If your patch program cannot handle it, you may want to apply it manually (basically you have to remove/comment out two sections of code in setup.py). It seems that there are actually two bugs: 1. setup.py doesn't continue after trying to import the _ctypes extension. No idea why, but somewhere something exists the process. 2. _ctypes.so does not build (or better fails to load) because of missing symbols: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN I have no access to an AIX system, do I cannot try this out myself. One thing that comes to mind: These functions are implemented in the file Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c. This file is compiled, without errors. One problem could be that the whole file contents are included in an #ifdef block like this: #ifdef __ppc__ ... #endif Can it be that __ppc__ is not defined on this system? Can someone try out to build with these two lines removed? Thanks. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 10:55 Message: Logged In: YES user_id=1645242 What is the status on this bug? I tried the work around, but patch doesn't like the diff file provided, says "Processing... I cannot find a patch in there anywhere." ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:55 Message: Logged In: YES user_id=129055 Build finished running; full log attached as python-2.5- ctypes.log.gz. Relevent lines are: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep [... more ld errors ...] collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 And at this point gmake exits and the build stops. Running gmake again just causes the same error to pop up. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:29 Message: Logged In: YES user_id=129055 Ah, well there is a bug then... setup.py does not continue on its own. I've added an attachement of a successful full build log (built with the noctypes patch), and will attach a second full build log that shows the build failing on the error when it finishes running in 10-20 minutes... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 08:14 Message: Logged In: YES user_id=21627 No; setup.py should continue on its own. If it doesn't, that's a bug. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:06 Message: Logged In: YES user_id=129055 loewis: No, the ctypes error messages cause the build to fail. Are you saying to use "gmake -k" or something like that? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 07:15 Message: Logged In: YES user_id=21627 You don't need to disable it. It will print error messages, but you can just ignore them if you don't need the ctypes module. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 23:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 22:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 20:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Tue Nov 14 20:29:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Nov 2006 11:29:09 -0800 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-22 20:07 Message generated for change (Comment added) made by memotype You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 Please note that this 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 Private: No Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 14:29 Message: Logged In: YES user_id=1645242 Originator: NO Ohh, and before you ask (I forgot to mention): grepping for "ppc" (with -i) doesn't yield any more results. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 14:25 Message: Logged In: YES user_id=1645242 Originator: NO I'm sorry, I meant __ppc__, it was the __ppc__ lines that I removed. As for PPC specific defines, I can't find any that work, but grepping around in /usr/include shows: /usr/include $ grep -i powerpc * aouthdr.h: * Defines for the POWER and PowerPC CPU Types aouthdr.h:#define TCPU_PPC 1 /* PowerPC common architecture 32 bit mode */ aouthdr.h:#define TCPU_PPC64 2 /* PowerPC common architecture 64 bit mode */ aouthdr.h:#define TCPU_COM 3 /* POWER and PowerPC architecture common */ aouthdr.h: /* and PowerPC architecture implementations */ aouthdr.h:#define TCPU_601 6 /* 601 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_603 7 /* 603 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_604 8 /* 604 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_620 16 /* 620 implementation of PowerPC 64-bit architecture */ aouthdr.h:#define TCPU_A35 17 /* A35 implementation of PowerPC 64-bit architecture */ filehdr.h:/* IBM POWER and PowerPC */ frs.h:| - rom_scan_R2_6002_block_t (PowerPC devices) frs.h:| - rom_scan_R2_6003_block_t (60x PowerPC devices) frs.h:| The PowerPC 601 Bus has such characteristics. frs.h:| that matches the PowerPC 60X Bus and PowerPC System Architecture frs_60x.h: | as defined by PowerPC System ARch and unique frs_60x.h:| PowerPC Feature/VPD Header reloc.h: * POWER and PowerPC - relocation types I would love to send you a copy of the aouthdr.h, but I'm not sure if that would violate any licenses, so I will have to leave the rest to you guys to look for some definitive documentation as to how to detect ppc from defines. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-14 14:08 Message: Logged In: YES user_id=21627 Originator: NO Please compile an empty file with "gcc -E -dD empty.c" to find out what defines are builtin. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 13:47 Message: Logged In: YES user_id=11105 Originator: NO Hm, I was asking for '__ppc__', not '__aix__'. Can you look for processor specific defines, please? ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 13:35 Message: Logged In: YES user_id=1645242 Originator: NO _AIX however, /is/ defined, so maybe s/__aix__/_AIX/g? ~/Python-2.5 $ cat <<. > test.c > int main() { > #ifdef _AIX > return 0; > #endif > #ifndef _AIX > return 1; > #endif > } > . ~/Python-2.5 $ gcc -o test test.c ~/Python-2.5 $ ./test ~/Python-2.5 $ echo $? 0 ~/Python-2.5 $ ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 13:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 13:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 12:05 Message: Logged In: YES user_id=11105 Well, there is certainly a diff in noctypes.diff. If your patch program cannot handle it, you may want to apply it manually (basically you have to remove/comment out two sections of code in setup.py). It seems that there are actually two bugs: 1. setup.py doesn't continue after trying to import the _ctypes extension. No idea why, but somewhere something exists the process. 2. _ctypes.so does not build (or better fails to load) because of missing symbols: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN I have no access to an AIX system, do I cannot try this out myself. One thing that comes to mind: These functions are implemented in the file Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c. This file is compiled, without errors. One problem could be that the whole file contents are included in an #ifdef block like this: #ifdef __ppc__ ... #endif Can it be that __ppc__ is not defined on this system? Can someone try out to build with these two lines removed? Thanks. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 10:55 Message: Logged In: YES user_id=1645242 What is the status on this bug? I tried the work around, but patch doesn't like the diff file provided, says "Processing... I cannot find a patch in there anywhere." ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:55 Message: Logged In: YES user_id=129055 Build finished running; full log attached as python-2.5- ctypes.log.gz. Relevent lines are: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep [... more ld errors ...] collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 And at this point gmake exits and the build stops. Running gmake again just causes the same error to pop up. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:29 Message: Logged In: YES user_id=129055 Ah, well there is a bug then... setup.py does not continue on its own. I've added an attachement of a successful full build log (built with the noctypes patch), and will attach a second full build log that shows the build failing on the error when it finishes running in 10-20 minutes... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 08:14 Message: Logged In: YES user_id=21627 No; setup.py should continue on its own. If it doesn't, that's a bug. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:06 Message: Logged In: YES user_id=129055 loewis: No, the ctypes error messages cause the build to fail. Are you saying to use "gmake -k" or something like that? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 07:15 Message: Logged In: YES user_id=21627 You don't need to disable it. It will print error messages, but you can just ignore them if you don't need the ctypes module. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 23:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 22:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 20:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Tue Nov 14 22:59:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Nov 2006 13:59:01 -0800 Subject: [ python-Bugs-1596321 ] KeyError at exit after 'import threading' in other thread Message-ID: Bugs item #1596321, was opened at 2006-11-14 06:02 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1596321&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Walther (cwalther) Assigned to: Nobody/Anonymous (nobody) Summary: KeyError at exit after 'import threading' in other thread Initial Comment: Python 2.4.3 on Windows 2000, though the code in question seems unchanged in current SVN (r46919). I'm using Python embedded in a multithreaded C++ application. When 'import threading' is first done in some Python script that runs in thread A, I get the following exception when a different thread B calls Py_Finalize(): Error in atexit._run_exitfuncs: Traceback (most recent call last): File "C:\Python24\lib\atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "C:\Python24\lib\threading.py", line 636, in __exitfunc self._Thread__delete() File "C:\Python24\lib\threading.py", line 522, in __delete del _active[_get_ident()] KeyError: 680 Error in sys.exitfunc: Traceback (most recent call last): File "C:\Python24\lib\atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "C:\Python24\lib\threading.py", line 636, in __exitfunc self._Thread__delete() File "C:\Python24\lib\threading.py", line 522, in __delete del _active[_get_ident()] KeyError: 680 The reason seems to be that the threading module uses the thread ID of the calling thread as a key to store its _MainThread instance on initialization, and again the thread ID of the calling thread to delete it in its exit function. If these two threads are not the same, the described KeyError occurs. I didn't study this in all detail, but it seems to me that threading.Thread.__delete() does the wrong thing. By doing 'del _active[_get_ident()]', it removes the instance for the calling thread from the _active dictionary. What it should be doing is removing *self* from that dictionary. Is that correct? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-11-14 13:59 Message: Logged In: YES user_id=357491 Originator: NO Well, I don't think you should be calling Py_Finalize() from the non-main thread. That just seems unsafe to me. Regardless, though, could you write up some quick Python code that triggers this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1596321&group_id=5470 From noreply at sourceforge.net Wed Nov 15 06:53:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Nov 2006 21:53:01 -0800 Subject: [ python-Bugs-1593384 ] No IDLE in Windows Message-ID: Bugs item #1593384, was opened at 2006-11-09 15:49 Message generated for change (Comment added) made by a_v_i You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: A_V_I (a_v_i) Assigned to: Nobody/Anonymous (nobody) Summary: No IDLE in Windows Initial Comment: I have installed Python 2.5 on WinXP using python-25.msi with all features included and all default direcories , etc. When I tried to use IDLE I had got the following results: - shortcut in Start -> ... does not do anything - no IDLE in Python25\Tools How can I get IDLE for usage? ---------------------------------------------------------------------- >Comment By: A_V_I (a_v_i) Date: 2006-11-15 08:53 Message: Logged In: YES user_id=1641322 Originator: YES Thatk you for your suggestion - those variables pointed at the older Python version. After I changed their values to Python 2.5 the magic returns. I would suggest to add information about TCL_LIBRARY and TK_LIBRARY environment variables into Installation instructions. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-14 21:39 Message: Logged In: YES user_id=21627 Originator: NO I wasn't asking that you remove the files: I asked that you remove (unset) the environment variables. ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-14 12:53 Message: Logged In: YES user_id=1641322 I have got both. When i remove c:\Python25\tcl the response is the same as before If in addition to that I remove c:\Python25\Lib\lib-tk it tells me that I do not have TCL/TK properly configured or it is not in the system ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-14 09:16 Message: Logged In: YES user_id=21627 Can you please check whether you have TCL_LIBRARY or TK_LIBRARY set in your environment, and, if so, try removing them? ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-14 08:59 Message: Logged In: YES user_id=1641322 Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\Administrator>C:\Python25\python.exe C:\Python25\Lib\i dlelib\idle.pyw Traceback (most recent call last): File "C:\Python25\Lib\idlelib\idle.pyw", line 21, in idlelib.PyShell.main() File "C:\Python25\lib\idlelib\PyShell.py", line 1388, in main root = Tk(className="Idle") File "C:\Python25\lib\lib-tk\Tkinter.py", line 1636, in __init__ self.tk = _tkinter.create(screenName, baseName, className, interactive, want objects, useTk, sync, use) _tkinter.TclError: Can't find a usable init.tcl in the following directories: {C:\IBMTOOLS\Python22\tcl\tcl8.4} {C:\IBMTOOLS\Python22\tcl\tcl8.4} C:/IBMTO OLS/Python22/tcl/tcl8.4 C:/Python25/lib/tcl8.4 C:/lib/tcl8.4 C:/library This probably means that Tcl wasn't installed properly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-13 21:16 Message: Logged In: YES user_id=21627 I see. Can you please run C:\Python25\python.exe C:\Python25\Lib\idlelib\idle.pyw in a cmd.exe window and report what happens? ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-13 14:33 Message: Logged In: YES user_id=1641322 Properties: IDLE (Python GUI) Target Python 2.5 Start in C:\Python25 Shortcut key None Run Normal window ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-13 14:33 Message: Logged In: YES user_id=1641322 Properties: IDLE (Python GUI) Target Python 2.5 Start in C:\Python25 Shortcut key None Run Normal window ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-09 22:35 Message: Logged In: YES user_id=21627 Can you please report the properties of the IDLE shortcut? (right-button on the start menu item, properties) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 From noreply at sourceforge.net Wed Nov 15 07:29:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Nov 2006 22:29:36 -0800 Subject: [ python-Bugs-1593384 ] No IDLE in Windows Message-ID: Bugs item #1593384, was opened at 2006-11-09 13:49 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 Please note that this 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: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: A_V_I (a_v_i) Assigned to: Nobody/Anonymous (nobody) Summary: No IDLE in Windows Initial Comment: I have installed Python 2.5 on WinXP using python-25.msi with all features included and all default direcories , etc. When I tried to use IDLE I had got the following results: - shortcut in Start -> ... does not do anything - no IDLE in Python25\Tools How can I get IDLE for usage? ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-15 07:29 Message: Logged In: YES user_id=21627 Originator: NO Please don't change the variables to point elsewhere: remove them entirely, completely, totally from your system. Otherwise, if you install another tcl-needing application, it will break again. Closing this as fixed. ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-15 06:53 Message: Logged In: YES user_id=1641322 Originator: YES Thatk you for your suggestion - those variables pointed at the older Python version. After I changed their values to Python 2.5 the magic returns. I would suggest to add information about TCL_LIBRARY and TK_LIBRARY environment variables into Installation instructions. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-14 19:39 Message: Logged In: YES user_id=21627 Originator: NO I wasn't asking that you remove the files: I asked that you remove (unset) the environment variables. ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-14 10:53 Message: Logged In: YES user_id=1641322 I have got both. When i remove c:\Python25\tcl the response is the same as before If in addition to that I remove c:\Python25\Lib\lib-tk it tells me that I do not have TCL/TK properly configured or it is not in the system ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-14 07:16 Message: Logged In: YES user_id=21627 Can you please check whether you have TCL_LIBRARY or TK_LIBRARY set in your environment, and, if so, try removing them? ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-14 06:59 Message: Logged In: YES user_id=1641322 Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\Administrator>C:\Python25\python.exe C:\Python25\Lib\i dlelib\idle.pyw Traceback (most recent call last): File "C:\Python25\Lib\idlelib\idle.pyw", line 21, in idlelib.PyShell.main() File "C:\Python25\lib\idlelib\PyShell.py", line 1388, in main root = Tk(className="Idle") File "C:\Python25\lib\lib-tk\Tkinter.py", line 1636, in __init__ self.tk = _tkinter.create(screenName, baseName, className, interactive, want objects, useTk, sync, use) _tkinter.TclError: Can't find a usable init.tcl in the following directories: {C:\IBMTOOLS\Python22\tcl\tcl8.4} {C:\IBMTOOLS\Python22\tcl\tcl8.4} C:/IBMTO OLS/Python22/tcl/tcl8.4 C:/Python25/lib/tcl8.4 C:/lib/tcl8.4 C:/library This probably means that Tcl wasn't installed properly. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-13 19:16 Message: Logged In: YES user_id=21627 I see. Can you please run C:\Python25\python.exe C:\Python25\Lib\idlelib\idle.pyw in a cmd.exe window and report what happens? ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-13 12:33 Message: Logged In: YES user_id=1641322 Properties: IDLE (Python GUI) Target Python 2.5 Start in C:\Python25 Shortcut key None Run Normal window ---------------------------------------------------------------------- Comment By: A_V_I (a_v_i) Date: 2006-11-13 12:33 Message: Logged In: YES user_id=1641322 Properties: IDLE (Python GUI) Target Python 2.5 Start in C:\Python25 Shortcut key None Run Normal window ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-09 20:35 Message: Logged In: YES user_id=21627 Can you please report the properties of the IDLE shortcut? (right-button on the start menu item, properties) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593384&group_id=5470 From noreply at sourceforge.net Wed Nov 15 08:02:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 14 Nov 2006 23:02:23 -0800 Subject: [ python-Bugs-1596321 ] KeyError at exit after 'import threading' in other thread Message-ID: Bugs item #1596321, was opened at 2006-11-14 15:02 Message generated for change (Comment added) made by cwalther You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1596321&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Walther (cwalther) Assigned to: Nobody/Anonymous (nobody) Summary: KeyError at exit after 'import threading' in other thread Initial Comment: Python 2.4.3 on Windows 2000, though the code in question seems unchanged in current SVN (r46919). I'm using Python embedded in a multithreaded C++ application. When 'import threading' is first done in some Python script that runs in thread A, I get the following exception when a different thread B calls Py_Finalize(): Error in atexit._run_exitfuncs: Traceback (most recent call last): File "C:\Python24\lib\atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "C:\Python24\lib\threading.py", line 636, in __exitfunc self._Thread__delete() File "C:\Python24\lib\threading.py", line 522, in __delete del _active[_get_ident()] KeyError: 680 Error in sys.exitfunc: Traceback (most recent call last): File "C:\Python24\lib\atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "C:\Python24\lib\threading.py", line 636, in __exitfunc self._Thread__delete() File "C:\Python24\lib\threading.py", line 522, in __delete del _active[_get_ident()] KeyError: 680 The reason seems to be that the threading module uses the thread ID of the calling thread as a key to store its _MainThread instance on initialization, and again the thread ID of the calling thread to delete it in its exit function. If these two threads are not the same, the described KeyError occurs. I didn't study this in all detail, but it seems to me that threading.Thread.__delete() does the wrong thing. By doing 'del _active[_get_ident()]', it removes the instance for the calling thread from the _active dictionary. What it should be doing is removing *self* from that dictionary. Is that correct? ---------------------------------------------------------------------- >Comment By: Christian Walther (cwalther) Date: 2006-11-15 08:02 Message: Logged In: YES user_id=1061789 Originator: YES I'm not calling Py_Finalize from a non-main thread. What I called "thread B" is the main thread. It's the script that first imports the threading module that runs in a non-main thread (and running user-defined scripts in non-main threads is hopefully not unsafe, or there wouldn't be much point in supporting multithreading at all in Python). It didn't even occur to me that this could be reproduced in pure Python code, so I didn't include an example in my original post. Of course, it can - see attachment. Tested on Python 2.3.5 on Mac OS X. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-11-14 22:59 Message: Logged In: YES user_id=357491 Originator: NO Well, I don't think you should be calling Py_Finalize() from the non-main thread. That just seems unsafe to me. Regardless, though, could you write up some quick Python code that triggers this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1596321&group_id=5470 From noreply at sourceforge.net Wed Nov 15 11:05:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Nov 2006 02:05:07 -0800 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-23 02:07 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 Please note that this 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 Private: No Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-11-15 11:05 Message: Logged In: YES user_id=11105 Originator: NO memotype, can you please do what loewis suggested and report back: > Please compile an empty file with "gcc -E -dD empty.c" to find out what > defines are builtin. It is very likely that the symbol we need is a builtin symbol of the compiler, and not a symbol defined in some of the header files. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 20:29 Message: Logged In: YES user_id=1645242 Originator: NO Ohh, and before you ask (I forgot to mention): grepping for "ppc" (with -i) doesn't yield any more results. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 20:25 Message: Logged In: YES user_id=1645242 Originator: NO I'm sorry, I meant __ppc__, it was the __ppc__ lines that I removed. As for PPC specific defines, I can't find any that work, but grepping around in /usr/include shows: /usr/include $ grep -i powerpc * aouthdr.h: * Defines for the POWER and PowerPC CPU Types aouthdr.h:#define TCPU_PPC 1 /* PowerPC common architecture 32 bit mode */ aouthdr.h:#define TCPU_PPC64 2 /* PowerPC common architecture 64 bit mode */ aouthdr.h:#define TCPU_COM 3 /* POWER and PowerPC architecture common */ aouthdr.h: /* and PowerPC architecture implementations */ aouthdr.h:#define TCPU_601 6 /* 601 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_603 7 /* 603 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_604 8 /* 604 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_620 16 /* 620 implementation of PowerPC 64-bit architecture */ aouthdr.h:#define TCPU_A35 17 /* A35 implementation of PowerPC 64-bit architecture */ filehdr.h:/* IBM POWER and PowerPC */ frs.h:| - rom_scan_R2_6002_block_t (PowerPC devices) frs.h:| - rom_scan_R2_6003_block_t (60x PowerPC devices) frs.h:| The PowerPC 601 Bus has such characteristics. frs.h:| that matches the PowerPC 60X Bus and PowerPC System Architecture frs_60x.h: | as defined by PowerPC System ARch and unique frs_60x.h:| PowerPC Feature/VPD Header reloc.h: * POWER and PowerPC - relocation types I would love to send you a copy of the aouthdr.h, but I'm not sure if that would violate any licenses, so I will have to leave the rest to you guys to look for some definitive documentation as to how to detect ppc from defines. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-14 20:08 Message: Logged In: YES user_id=21627 Originator: NO Please compile an empty file with "gcc -E -dD empty.c" to find out what defines are builtin. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 19:47 Message: Logged In: YES user_id=11105 Originator: NO Hm, I was asking for '__ppc__', not '__aix__'. Can you look for processor specific defines, please? ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 19:35 Message: Logged In: YES user_id=1645242 Originator: NO _AIX however, /is/ defined, so maybe s/__aix__/_AIX/g? ~/Python-2.5 $ cat <<. > test.c > int main() { > #ifdef _AIX > return 0; > #endif > #ifndef _AIX > return 1; > #endif > } > . ~/Python-2.5 $ gcc -o test test.c ~/Python-2.5 $ ./test ~/Python-2.5 $ echo $? 0 ~/Python-2.5 $ ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 19:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 19:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 18:05 Message: Logged In: YES user_id=11105 Well, there is certainly a diff in noctypes.diff. If your patch program cannot handle it, you may want to apply it manually (basically you have to remove/comment out two sections of code in setup.py). It seems that there are actually two bugs: 1. setup.py doesn't continue after trying to import the _ctypes extension. No idea why, but somewhere something exists the process. 2. _ctypes.so does not build (or better fails to load) because of missing symbols: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN I have no access to an AIX system, do I cannot try this out myself. One thing that comes to mind: These functions are implemented in the file Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c. This file is compiled, without errors. One problem could be that the whole file contents are included in an #ifdef block like this: #ifdef __ppc__ ... #endif Can it be that __ppc__ is not defined on this system? Can someone try out to build with these two lines removed? Thanks. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 16:55 Message: Logged In: YES user_id=1645242 What is the status on this bug? I tried the work around, but patch doesn't like the diff file provided, says "Processing... I cannot find a patch in there anywhere." ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:55 Message: Logged In: YES user_id=129055 Build finished running; full log attached as python-2.5- ctypes.log.gz. Relevent lines are: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep [... more ld errors ...] collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 And at this point gmake exits and the build stops. Running gmake again just causes the same error to pop up. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:29 Message: Logged In: YES user_id=129055 Ah, well there is a bug then... setup.py does not continue on its own. I've added an attachement of a successful full build log (built with the noctypes patch), and will attach a second full build log that shows the build failing on the error when it finishes running in 10-20 minutes... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 14:14 Message: Logged In: YES user_id=21627 No; setup.py should continue on its own. If it doesn't, that's a bug. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:06 Message: Logged In: YES user_id=129055 loewis: No, the ctypes error messages cause the build to fail. Are you saying to use "gmake -k" or something like that? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 13:15 Message: Logged In: YES user_id=21627 You don't need to disable it. It will print error messages, but you can just ignore them if you don't need the ctypes module. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 05:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 04:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 02:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Wed Nov 15 14:00:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Nov 2006 05:00:38 -0800 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-22 20:07 Message generated for change (Comment added) made by memotype You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 Please note that this 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 Private: No Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-15 08:00 Message: Logged In: YES user_id=1645242 Originator: NO Something like this? ~ $ touch empty.c ~ $ gcc -E -dD empty.c # 1 "empty.c" ~ $ cat empty.c ~ $ ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-15 05:05 Message: Logged In: YES user_id=11105 Originator: NO memotype, can you please do what loewis suggested and report back: > Please compile an empty file with "gcc -E -dD empty.c" to find out what > defines are builtin. It is very likely that the symbol we need is a builtin symbol of the compiler, and not a symbol defined in some of the header files. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 14:29 Message: Logged In: YES user_id=1645242 Originator: NO Ohh, and before you ask (I forgot to mention): grepping for "ppc" (with -i) doesn't yield any more results. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 14:25 Message: Logged In: YES user_id=1645242 Originator: NO I'm sorry, I meant __ppc__, it was the __ppc__ lines that I removed. As for PPC specific defines, I can't find any that work, but grepping around in /usr/include shows: /usr/include $ grep -i powerpc * aouthdr.h: * Defines for the POWER and PowerPC CPU Types aouthdr.h:#define TCPU_PPC 1 /* PowerPC common architecture 32 bit mode */ aouthdr.h:#define TCPU_PPC64 2 /* PowerPC common architecture 64 bit mode */ aouthdr.h:#define TCPU_COM 3 /* POWER and PowerPC architecture common */ aouthdr.h: /* and PowerPC architecture implementations */ aouthdr.h:#define TCPU_601 6 /* 601 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_603 7 /* 603 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_604 8 /* 604 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_620 16 /* 620 implementation of PowerPC 64-bit architecture */ aouthdr.h:#define TCPU_A35 17 /* A35 implementation of PowerPC 64-bit architecture */ filehdr.h:/* IBM POWER and PowerPC */ frs.h:| - rom_scan_R2_6002_block_t (PowerPC devices) frs.h:| - rom_scan_R2_6003_block_t (60x PowerPC devices) frs.h:| The PowerPC 601 Bus has such characteristics. frs.h:| that matches the PowerPC 60X Bus and PowerPC System Architecture frs_60x.h: | as defined by PowerPC System ARch and unique frs_60x.h:| PowerPC Feature/VPD Header reloc.h: * POWER and PowerPC - relocation types I would love to send you a copy of the aouthdr.h, but I'm not sure if that would violate any licenses, so I will have to leave the rest to you guys to look for some definitive documentation as to how to detect ppc from defines. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-14 14:08 Message: Logged In: YES user_id=21627 Originator: NO Please compile an empty file with "gcc -E -dD empty.c" to find out what defines are builtin. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 13:47 Message: Logged In: YES user_id=11105 Originator: NO Hm, I was asking for '__ppc__', not '__aix__'. Can you look for processor specific defines, please? ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 13:35 Message: Logged In: YES user_id=1645242 Originator: NO _AIX however, /is/ defined, so maybe s/__aix__/_AIX/g? ~/Python-2.5 $ cat <<. > test.c > int main() { > #ifdef _AIX > return 0; > #endif > #ifndef _AIX > return 1; > #endif > } > . ~/Python-2.5 $ gcc -o test test.c ~/Python-2.5 $ ./test ~/Python-2.5 $ echo $? 0 ~/Python-2.5 $ ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 13:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 13:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 12:05 Message: Logged In: YES user_id=11105 Well, there is certainly a diff in noctypes.diff. If your patch program cannot handle it, you may want to apply it manually (basically you have to remove/comment out two sections of code in setup.py). It seems that there are actually two bugs: 1. setup.py doesn't continue after trying to import the _ctypes extension. No idea why, but somewhere something exists the process. 2. _ctypes.so does not build (or better fails to load) because of missing symbols: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN I have no access to an AIX system, do I cannot try this out myself. One thing that comes to mind: These functions are implemented in the file Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c. This file is compiled, without errors. One problem could be that the whole file contents are included in an #ifdef block like this: #ifdef __ppc__ ... #endif Can it be that __ppc__ is not defined on this system? Can someone try out to build with these two lines removed? Thanks. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 10:55 Message: Logged In: YES user_id=1645242 What is the status on this bug? I tried the work around, but patch doesn't like the diff file provided, says "Processing... I cannot find a patch in there anywhere." ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:55 Message: Logged In: YES user_id=129055 Build finished running; full log attached as python-2.5- ctypes.log.gz. Relevent lines are: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep [... more ld errors ...] collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 And at this point gmake exits and the build stops. Running gmake again just causes the same error to pop up. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:29 Message: Logged In: YES user_id=129055 Ah, well there is a bug then... setup.py does not continue on its own. I've added an attachement of a successful full build log (built with the noctypes patch), and will attach a second full build log that shows the build failing on the error when it finishes running in 10-20 minutes... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 08:14 Message: Logged In: YES user_id=21627 No; setup.py should continue on its own. If it doesn't, that's a bug. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:06 Message: Logged In: YES user_id=129055 loewis: No, the ctypes error messages cause the build to fail. Are you saying to use "gmake -k" or something like that? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 07:15 Message: Logged In: YES user_id=21627 You don't need to disable it. It will print error messages, but you can just ignore them if you don't need the ctypes module. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 23:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 22:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 20:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Wed Nov 15 14:36:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Nov 2006 05:36:36 -0800 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-23 02:07 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 Please note that this 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 Private: No Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-11-15 14:36 Message: Logged In: YES user_id=11105 Originator: NO Yes ;-), although I would have expected that 'gcc -E -dD empty.c' would have printed something. Does 'touch empty.c; cpp -dM empty.c' print something? ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-15 14:00 Message: Logged In: YES user_id=1645242 Originator: NO Something like this? ~ $ touch empty.c ~ $ gcc -E -dD empty.c # 1 "empty.c" ~ $ cat empty.c ~ $ ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-15 11:05 Message: Logged In: YES user_id=11105 Originator: NO memotype, can you please do what loewis suggested and report back: > Please compile an empty file with "gcc -E -dD empty.c" to find out what > defines are builtin. It is very likely that the symbol we need is a builtin symbol of the compiler, and not a symbol defined in some of the header files. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 20:29 Message: Logged In: YES user_id=1645242 Originator: NO Ohh, and before you ask (I forgot to mention): grepping for "ppc" (with -i) doesn't yield any more results. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 20:25 Message: Logged In: YES user_id=1645242 Originator: NO I'm sorry, I meant __ppc__, it was the __ppc__ lines that I removed. As for PPC specific defines, I can't find any that work, but grepping around in /usr/include shows: /usr/include $ grep -i powerpc * aouthdr.h: * Defines for the POWER and PowerPC CPU Types aouthdr.h:#define TCPU_PPC 1 /* PowerPC common architecture 32 bit mode */ aouthdr.h:#define TCPU_PPC64 2 /* PowerPC common architecture 64 bit mode */ aouthdr.h:#define TCPU_COM 3 /* POWER and PowerPC architecture common */ aouthdr.h: /* and PowerPC architecture implementations */ aouthdr.h:#define TCPU_601 6 /* 601 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_603 7 /* 603 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_604 8 /* 604 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_620 16 /* 620 implementation of PowerPC 64-bit architecture */ aouthdr.h:#define TCPU_A35 17 /* A35 implementation of PowerPC 64-bit architecture */ filehdr.h:/* IBM POWER and PowerPC */ frs.h:| - rom_scan_R2_6002_block_t (PowerPC devices) frs.h:| - rom_scan_R2_6003_block_t (60x PowerPC devices) frs.h:| The PowerPC 601 Bus has such characteristics. frs.h:| that matches the PowerPC 60X Bus and PowerPC System Architecture frs_60x.h: | as defined by PowerPC System ARch and unique frs_60x.h:| PowerPC Feature/VPD Header reloc.h: * POWER and PowerPC - relocation types I would love to send you a copy of the aouthdr.h, but I'm not sure if that would violate any licenses, so I will have to leave the rest to you guys to look for some definitive documentation as to how to detect ppc from defines. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-14 20:08 Message: Logged In: YES user_id=21627 Originator: NO Please compile an empty file with "gcc -E -dD empty.c" to find out what defines are builtin. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 19:47 Message: Logged In: YES user_id=11105 Originator: NO Hm, I was asking for '__ppc__', not '__aix__'. Can you look for processor specific defines, please? ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 19:35 Message: Logged In: YES user_id=1645242 Originator: NO _AIX however, /is/ defined, so maybe s/__aix__/_AIX/g? ~/Python-2.5 $ cat <<. > test.c > int main() { > #ifdef _AIX > return 0; > #endif > #ifndef _AIX > return 1; > #endif > } > . ~/Python-2.5 $ gcc -o test test.c ~/Python-2.5 $ ./test ~/Python-2.5 $ echo $? 0 ~/Python-2.5 $ ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 19:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 19:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 18:05 Message: Logged In: YES user_id=11105 Well, there is certainly a diff in noctypes.diff. If your patch program cannot handle it, you may want to apply it manually (basically you have to remove/comment out two sections of code in setup.py). It seems that there are actually two bugs: 1. setup.py doesn't continue after trying to import the _ctypes extension. No idea why, but somewhere something exists the process. 2. _ctypes.so does not build (or better fails to load) because of missing symbols: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN I have no access to an AIX system, do I cannot try this out myself. One thing that comes to mind: These functions are implemented in the file Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c. This file is compiled, without errors. One problem could be that the whole file contents are included in an #ifdef block like this: #ifdef __ppc__ ... #endif Can it be that __ppc__ is not defined on this system? Can someone try out to build with these two lines removed? Thanks. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 16:55 Message: Logged In: YES user_id=1645242 What is the status on this bug? I tried the work around, but patch doesn't like the diff file provided, says "Processing... I cannot find a patch in there anywhere." ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:55 Message: Logged In: YES user_id=129055 Build finished running; full log attached as python-2.5- ctypes.log.gz. Relevent lines are: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep [... more ld errors ...] collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 And at this point gmake exits and the build stops. Running gmake again just causes the same error to pop up. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:29 Message: Logged In: YES user_id=129055 Ah, well there is a bug then... setup.py does not continue on its own. I've added an attachement of a successful full build log (built with the noctypes patch), and will attach a second full build log that shows the build failing on the error when it finishes running in 10-20 minutes... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 14:14 Message: Logged In: YES user_id=21627 No; setup.py should continue on its own. If it doesn't, that's a bug. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:06 Message: Logged In: YES user_id=129055 loewis: No, the ctypes error messages cause the build to fail. Are you saying to use "gmake -k" or something like that? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 13:15 Message: Logged In: YES user_id=21627 You don't need to disable it. It will print error messages, but you can just ignore them if you don't need the ctypes module. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 05:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 04:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 02:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Wed Nov 15 14:49:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Nov 2006 05:49:41 -0800 Subject: [ python-Bugs-1594966 ] doctest simple usage recipe is misleading Message-ID: Bugs item #1594966, was opened at 2006-11-12 03:31 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594966&group_id=5470 Please note that this 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 Private: No Submitted By: Ken Rimey (yemir) >Assigned to: Tim Peters (tim_one) Summary: doctest simple usage recipe is misleading Initial Comment: "23.2.1 Simple Usage: Checking Examples in Docstrings" sets up a trap for the unsuspecting developer: http://docs.python.org/lib/doctest-simple-testmod.html That page recommends adding the following code to the end of a module using doctest: def _test(): import doctest doctest.testmod() if __name__ == "__main__": _test() The problem is that a reasonable person will figure that _test() has been defined for convenience in executing the tests from other Python code as follows: import M M._test() However, that executes the doctests found in __main__, not M! I think the recommended recipe should instead be as follows: if __name__ == "__main__": import doctest doctest.testmod() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594966&group_id=5470 From noreply at sourceforge.net Wed Nov 15 15:01:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Nov 2006 06:01:58 -0800 Subject: [ python-Bugs-1597000 ] HTTP headers Message-ID: Bugs item #1597000, was opened at 2006-11-15 15: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=1597000&group_id=5470 Please note that this 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 Private: No Submitted By: Hugo Leisink (hiawatha) Assigned to: Nobody/Anonymous (nobody) Summary: HTTP headers Initial Comment: A HTTP headerline must end with CRLF (\r\n) instead of only LF (\n). Python only uses the LF to end a HTTP headerline (cgitb.enable() for example). Also, in many Python documents, only LF is being used. For more information about this issue, see the HTTP RFC (2616), section 6 (Response). Hugo Leisink (hugo at leisink.net) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597000&group_id=5470 From noreply at sourceforge.net Wed Nov 15 15:19:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Nov 2006 06:19:09 -0800 Subject: [ python-Bugs-1597011 ] Reading with bz2.BZ2File() returns one garbage character Message-ID: Bugs item #1597011, was opened at 2006-11-15 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=1597011&group_id=5470 Please note that this 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 Private: No Submitted By: Clodoaldo Pinto Neto (cpn) Assigned to: Nobody/Anonymous (nobody) Summary: Reading with bz2.BZ2File() returns one garbage character Initial Comment: When comparing two files which should be equal the last line is different: The first file is a bzip2 compressed file and is read with bz2.BZ2File() The second file is the same file uncompressed and read with open() The first file named file.txt.bz2 is uncompressed with: $ bunzip2 -k file.txt.bz2 To compare I use this script: ############################### import bz2 f1 = bz2.BZ2File(r'file.txt.bz2', 'r') f2 = open(r'file.txt', 'r') lines = 0 while True: line1 = f1.readline() line2 = f2.readline() if line1 == '': break lines += 1 if line1 != line2: print 'line number:', lines print repr(line1) print repr(line2) f1.close() f2.close() ############################## Output: $ python bzp.py line number: 588317 '\x07' '' The offending attached file is 5.5 MB. Sorry, i could not reproduce this problem with a smaller file. Tested in Fedora Core 5 and Python 2.4.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597011&group_id=5470 From noreply at sourceforge.net Wed Nov 15 15:27:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Nov 2006 06:27:41 -0800 Subject: [ python-Bugs-1597014 ] Can't exclude words before capture group Message-ID: Bugs item #1597014, was opened at 2006-11-15 14:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597014&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Cees Timmerman (ctimmerman) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Can't exclude words before capture group Initial Comment: Python 2.4.3 (#2, Oct 6 2006, 07:52:30) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Tried: >>> re.findall(r'(?!def)\b(\S+)\(', "def bla(): dof blu()") >>> re.findall(r'(?:def){0}\b(\S+)\(', "def bla(): dof blu()") Result: ['bla', 'blu'] Expected: ['blu'] Why doesn't (?!) work like it does here?: >>> re.findall(r'\b(\S+): (?!bad)', "bob: bad; suzy: good") ['suzy'] Wouldn't it be nice if (^) worked? >>> re.findall(r'\b(\S+): (^bad)', "bob: bad; suzy: good") [] [^()] does, sorta. Also not before a capture group: >>> re.findall(r'\b(\S+): [^(bad)]', "bob: bad; suzy: good") ['suzy'] >>> re.findall(r'[^(def)]\b(\S+)\(', "def bla(): dof blu()") ['bla', 'blu'] >>> re.findall(r'[^(def)] (\S+)\(', "def bla(): dof blu()") [] >>> re.findall(r'(^def) (\S+)\(', "def bla(): dof blu()") [('def', 'bla')] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597014&group_id=5470 From noreply at sourceforge.net Wed Nov 15 15:28:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Nov 2006 06:28:41 -0800 Subject: [ python-Bugs-1597011 ] Reading with bz2.BZ2File() returns one garbage character Message-ID: Bugs item #1597011, was opened at 2006-11-15 12:19 Message generated for change (Comment added) made by cpn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597011&group_id=5470 Please note that this 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 Private: No Submitted By: Clodoaldo Pinto Neto (cpn) Assigned to: Nobody/Anonymous (nobody) Summary: Reading with bz2.BZ2File() returns one garbage character Initial Comment: When comparing two files which should be equal the last line is different: The first file is a bzip2 compressed file and is read with bz2.BZ2File() The second file is the same file uncompressed and read with open() The first file named file.txt.bz2 is uncompressed with: $ bunzip2 -k file.txt.bz2 To compare I use this script: ############################### import bz2 f1 = bz2.BZ2File(r'file.txt.bz2', 'r') f2 = open(r'file.txt', 'r') lines = 0 while True: line1 = f1.readline() line2 = f2.readline() if line1 == '': break lines += 1 if line1 != line2: print 'line number:', lines print repr(line1) print repr(line2) f1.close() f2.close() ############################## Output: $ python bzp.py line number: 588317 '\x07' '' The offending attached file is 5.5 MB. Sorry, i could not reproduce this problem with a smaller file. Tested in Fedora Core 5 and Python 2.4.3 ---------------------------------------------------------------------- >Comment By: Clodoaldo Pinto Neto (cpn) Date: 2006-11-15 12:28 Message: Logged In: YES user_id=1646083 Originator: YES I can't upload the bz2 sample file. So it is here: http://fahstats.com/img/file.txt.bz2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597011&group_id=5470 From noreply at sourceforge.net Wed Nov 15 15:35:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Nov 2006 06:35:12 -0800 Subject: [ python-Bugs-1597011 ] Reading with bz2.BZ2File() returns one garbage character Message-ID: Bugs item #1597011, was opened at 2006-11-15 12:19 Message generated for change (Comment added) made by cpn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597011&group_id=5470 Please note that this 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 Private: No Submitted By: Clodoaldo Pinto Neto (cpn) Assigned to: Nobody/Anonymous (nobody) Summary: Reading with bz2.BZ2File() returns one garbage character Initial Comment: When comparing two files which should be equal the last line is different: The first file is a bzip2 compressed file and is read with bz2.BZ2File() The second file is the same file uncompressed and read with open() The first file named file.txt.bz2 is uncompressed with: $ bunzip2 -k file.txt.bz2 To compare I use this script: ############################### import bz2 f1 = bz2.BZ2File(r'file.txt.bz2', 'r') f2 = open(r'file.txt', 'r') lines = 0 while True: line1 = f1.readline() line2 = f2.readline() if line1 == '': break lines += 1 if line1 != line2: print 'line number:', lines print repr(line1) print repr(line2) f1.close() f2.close() ############################## Output: $ python bzp.py line number: 588317 '\x07' '' The offending attached file is 5.5 MB. Sorry, i could not reproduce this problem with a smaller file. Tested in Fedora Core 5 and Python 2.4.3 ---------------------------------------------------------------------- >Comment By: Clodoaldo Pinto Neto (cpn) Date: 2006-11-15 12:35 Message: Logged In: YES user_id=1646083 Originator: YES Confirmed in Windows Python 2.4 and 2.5 http://groups.google.com/group/comp.lang.python/tree/browse_frm/thread/3010fd664d78010f/4166d429b25c9ed4?rnum=1&_done=%2Fgroup%2Fcomp.lang.python%2Fbrowse_frm%2Fthread%2F3010fd664d78010f%2F4166d429b25c9ed4%3Ftvc%3D1%26#doc_7770aa47861db452 ---------------------------------------------------------------------- Comment By: Clodoaldo Pinto Neto (cpn) Date: 2006-11-15 12:28 Message: Logged In: YES user_id=1646083 Originator: YES I can't upload the bz2 sample file. So it is here: http://fahstats.com/img/file.txt.bz2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597011&group_id=5470 From noreply at sourceforge.net Wed Nov 15 18:20:38 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Nov 2006 09:20:38 -0800 Subject: [ python-Bugs-1597014 ] Can't exclude words before capture group Message-ID: Bugs item #1597014, was opened at 2006-11-15 14:27 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597014&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Cees Timmerman (ctimmerman) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Can't exclude words before capture group Initial Comment: Python 2.4.3 (#2, Oct 6 2006, 07:52:30) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Tried: >>> re.findall(r'(?!def)\b(\S+)\(', "def bla(): dof blu()") >>> re.findall(r'(?:def){0}\b(\S+)\(', "def bla(): dof blu()") Result: ['bla', 'blu'] Expected: ['blu'] Why doesn't (?!) work like it does here?: >>> re.findall(r'\b(\S+): (?!bad)', "bob: bad; suzy: good") ['suzy'] Wouldn't it be nice if (^) worked? >>> re.findall(r'\b(\S+): (^bad)', "bob: bad; suzy: good") [] [^()] does, sorta. Also not before a capture group: >>> re.findall(r'\b(\S+): [^(bad)]', "bob: bad; suzy: good") ['suzy'] >>> re.findall(r'[^(def)]\b(\S+)\(', "def bla(): dof blu()") ['bla', 'blu'] >>> re.findall(r'[^(def)] (\S+)\(', "def bla(): dof blu()") [] >>> re.findall(r'(^def) (\S+)\(', "def bla(): dof blu()") [('def', 'bla')] ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-15 17:20 Message: Logged In: YES user_id=849994 Originator: NO What you want is >>> re.findall(r'(? Bugs item #1597011, was opened at 2006-11-15 14:19 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597011&group_id=5470 Please note that this 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: 7 Private: No Submitted By: Clodoaldo Pinto Neto (cpn) Assigned to: Nobody/Anonymous (nobody) Summary: Reading with bz2.BZ2File() returns one garbage character Initial Comment: When comparing two files which should be equal the last line is different: The first file is a bzip2 compressed file and is read with bz2.BZ2File() The second file is the same file uncompressed and read with open() The first file named file.txt.bz2 is uncompressed with: $ bunzip2 -k file.txt.bz2 To compare I use this script: ############################### import bz2 f1 = bz2.BZ2File(r'file.txt.bz2', 'r') f2 = open(r'file.txt', 'r') lines = 0 while True: line1 = f1.readline() line2 = f2.readline() if line1 == '': break lines += 1 if line1 != line2: print 'line number:', lines print repr(line1) print repr(line2) f1.close() f2.close() ############################## Output: $ python bzp.py line number: 588317 '\x07' '' The offending attached file is 5.5 MB. Sorry, i could not reproduce this problem with a smaller file. Tested in Fedora Core 5 and Python 2.4.3 ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-15 17:30 Message: Logged In: YES user_id=849994 Originator: NO With your file, I can reproduce that on Linux, Python 2.5. Which compressor did you compress your file with? I unpacked it with bunzip2 without problems, then recompressed it with bzip2, which resulted in a slightly smaller (51 bytes) file, which then didn't trigger the bug. ---------------------------------------------------------------------- Comment By: Clodoaldo Pinto Neto (cpn) Date: 2006-11-15 14:35 Message: Logged In: YES user_id=1646083 Originator: YES Confirmed in Windows Python 2.4 and 2.5 http://groups.google.com/group/comp.lang.python/tree/browse_frm/thread/3010fd664d78010f/4166d429b25c9ed4?rnum=1&_done=%2Fgroup%2Fcomp.lang.python%2Fbrowse_frm%2Fthread%2F3010fd664d78010f%2F4166d429b25c9ed4%3Ftvc%3D1%26#doc_7770aa47861db452 ---------------------------------------------------------------------- Comment By: Clodoaldo Pinto Neto (cpn) Date: 2006-11-15 14:28 Message: Logged In: YES user_id=1646083 Originator: YES I can't upload the bz2 sample file. So it is here: http://fahstats.com/img/file.txt.bz2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597011&group_id=5470 From noreply at sourceforge.net Wed Nov 15 18:32:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Nov 2006 09:32:39 -0800 Subject: [ python-Bugs-1597000 ] HTTP headers Message-ID: Bugs item #1597000, was opened at 2006-11-15 14:01 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597000&group_id=5470 Please note that this 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 Private: No Submitted By: Hugo Leisink (hiawatha) Assigned to: Nobody/Anonymous (nobody) Summary: HTTP headers Initial Comment: A HTTP headerline must end with CRLF (\r\n) instead of only LF (\n). Python only uses the LF to end a HTTP headerline (cgitb.enable() for example). Also, in many Python documents, only LF is being used. For more information about this issue, see the HTTP RFC (2616), section 6 (Response). Hugo Leisink (hugo at leisink.net) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-15 17:32 Message: Logged In: YES user_id=849994 Originator: NO Do you want to work on a patch for that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597000&group_id=5470 From noreply at sourceforge.net Wed Nov 15 18:34:27 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Nov 2006 09:34:27 -0800 Subject: [ python-Bugs-1595742 ] SocketServer allow_reuse_address checked in constructor Message-ID: Bugs item #1595742, was opened at 2006-11-13 16:54 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595742&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Peter Parente (parente) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer allow_reuse_address checked in constructor Initial Comment: Python 2.4.3 (#1, Oct 1 2006, 18:00:19) [GCC 4.1.1 20060928 (Red Hat 4.1.1-28)] on linux2 The documentation in the SocketServer class indicates that the allow_reuse_address flag may be set on a SocketServer subclass *or instance.* However, the flag is read in a call to the server_bind() from the constructor of the server object. Therefore, setting the flag on a created instance has no effect. This is problematic when trying to set the flag on SimpleXMLRPCServer instances, for instance, which are often not subclassed. This flag should probably become one of the keyword arguments in the constructor of a SocketServer object. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-15 17:34 Message: Logged In: YES user_id=849994 Originator: NO Would you want to work on a patch for this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595742&group_id=5470 From noreply at sourceforge.net Wed Nov 15 18:42:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Nov 2006 09:42:21 -0800 Subject: [ python-Bugs-1594809 ] make install fails, various modules do not work Message-ID: Bugs item #1594809, was opened at 2006-11-11 20:27 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470 Please note that this 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: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Evan (erflynn) Assigned to: Nobody/Anonymous (nobody) Summary: make install fails, various modules do not work Initial Comment: I compiled Python 2.5 on a Linux user account on Debian 3.0. configure and make seemed to go okay, but make install failed at 'zipfile.py' when it was compiling modules into bytecode. I can still use the python interpreter. However, some important modules seem to be missing such as 'time' and 'operator'. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-15 17:42 Message: Logged In: YES user_id=849994 Originator: NO Done in rev. 52754, 52755 (2.5). ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-12 21:57 Message: Logged In: YES user_id=1642549 OK but there should be a note about this in the README: something like "if you are reinstalling Python or upgrading to a newer version, make sure to unset PYTHONHOME and PYTHONPATH." Or have the makefile use "python -E" while building Python. It is pretty strange to see a "make" run fine but the "make install" bombs. If you move compileall to the "make" stage, then you would know sooner if there was a problem. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 21:33 Message: Logged In: YES user_id=21627 Ok, closing this as "works for me" - if you set PYTHON* while building Python, you are on your own - don't do that, then. AFAICT, (a) running compileall during make would not have helped, it still would not have found the correct unicodedata module. (b) the installation doesn't rely on environment variables; as you found, they actually hurt. ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-12 21:03 Message: Logged In: YES user_id=1642549 As I understand it, these modules are actually shared libraries or 'extensions'. I unset PYTHONPATH and PYTHONHOME, and the build and install went just fine. Arrgh. I wonder why I had to set them in the first place... Thanks for the help. I'm not sure what the protocol is for creating source builds, but it might be nice if in the future the source distribution would (a) run compileall during make and not make install and (b) try to rely more on configure options and not environment variables. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 09:57 Message: Logged In: YES user_id=21627 Can you please do file build/lib.linux-i686-2.5/unicodedata.so and also, in ./python print sys.path According to your make.log, unicodedata.so ought to be present. ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-12 01:12 Message: Logged In: YES user_id=1642549 It could be a good start... erflynn at squall 267>./python -Wi -tt Python 2.5 (r25:51908, Nov 10 2006, 20:10:11) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import unicodedata Traceback (most recent call last): File "", line 1, in ImportError: No module named unicodedata >>> Maybe it's not linking some modules in? Would it be helpful if I let you SSH to the box? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 00:28 Message: Logged In: YES user_id=21627 I think I know what the cause of the problem is (although not the root cause): Compiling /home/cs/csugrads/erflynn/stow/python/lib/python2.5/test/test_multibytecodec.py ... Sorry: UnicodeError: ("\\N escapes not supported (can't load unicodedata module)",) So compilation for test_multibytecodec fails, causing compileall to fail. In the build directory, can you please run PYTHONPATH=/home/cs/csugrads/erflynn/stow/python/lib/python2.5 ./python -Wi -tt and do import unicodedata print unicodedata.ucnhash_CAPI import test.test_multibytecodec and report its output? ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-11 21:44 Message: Logged In: YES user_id=1642549 No I didn't run over quota. Running python in the directory it was built does not do anything differently. The logs indicate that 4 regression tests failed during 'make test'. This is reproducible. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-11-11 20:54 Message: Logged In: YES user_id=357491 Looking through the logs it looks like libinstall had an error. Did you run over quota in your home directory? The log for 'make' shows that 'time' was built. I bet if you run the Python executable in the directory where you compiled you will find you can import 'time' and such fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1594809&group_id=5470 From noreply at sourceforge.net Wed Nov 15 18:42:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Nov 2006 09:42:47 -0800 Subject: [ python-Bugs-1580563 ] "make install" for Python 2.4.4 not working properly Message-ID: Bugs item #1580563, was opened at 2006-10-19 14:21 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: "make install" for Python 2.4.4 not working properly Initial Comment: Running "make install" on Linux (Suse 10.1) won't terminate properly: Compiling /opt/python-2.4.4/lib/python2.4/user.py ... Compiling /opt/python-2.4.4/lib/python2.4/uu.py ... Compiling /opt/python-2.4.4/lib/python2.4/warnings.py ... Compiling /opt/python-2.4.4/lib/python2.4/wave.py ... Compiling /opt/python-2.4.4/lib/python2.4/weakref.py ... Compiling /opt/python-2.4.4/lib/python2.4/webbrowser.py ... Compiling /opt/python-2.4.4/lib/python2.4/whichdb.py ... Compiling /opt/python-2.4.4/lib/python2.4/whrandom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xdrlib.py ... Listing /opt/python-2.4.4/lib/python2.4/xml ... Compiling /opt/python-2.4.4/lib/python2.4/xml/__init__.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/dom ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/NodeFilter.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/domreg.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/expatbuilder.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/minicompat.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/minidom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/pulldom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/xmlbuilder.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/parsers ... Compiling /opt/python-2.4.4/lib/python2.4/xml/parsers/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/parsers/expat.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/sax ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/_exceptions.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/expatreader.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/handler.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/saxutils.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/xmlreader.py ... Compiling /opt/python-2.4.4/lib/python2.4/xmllib.py ... Compiling /opt/python-2.4.4/lib/python2.4/xmlrpclib.py ... Compiling /opt/python-2.4.4/lib/python2.4/zipfile.py ... make: *** [libinstall] Error 1 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 21:34 Message: Logged In: YES user_id=21627 ajung: can you please report what environment settings you are using? If you have set PYTHON* in your environment, make sure to unset all these variables. ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-11 20:29 Message: Logged In: YES user_id=1642549 I created a new bug report so I could attach a file. See #1594809 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-10 23:52 Message: Logged In: YES user_id=21627 Can you please provide a *complete* log file (i.e. terminal output) of the "make install" run? If SF rejects it because it is too large, try compressing it. ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-10 20:55 Message: Logged In: YES user_id=1642549 Hi, I am having exactly the same issue on Python 2.5. configure arguments have nothing special. This was on a Debian Woody system on which I have an account but not root access. Please let me know what to do in order to supply more information. ~Evan ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-20 07:52 Message: Logged In: YES user_id=21627 I can't reproduce this. It installs fine for me (although I try to install to /tmp/python-2.4.4, not opt), and also not on SuSE, but Debian unstable. Can you please debug through compileall, to find out whether and how exit_status gets set to a non-zero value? For that to happen, success should be set to 0 at some point. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2006-10-19 18:00 Message: Logged In: YES user_id=11084 On both system just "configure --prefix=/opt/python-2.4.4" ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-19 17:26 Message: Logged In: YES user_id=580910 What are the configure arguments that you are using? ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2006-10-19 14:33 Message: Logged In: YES user_id=11084 Same issue on MacOSX ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470 From noreply at sourceforge.net Wed Nov 15 18:46:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Nov 2006 09:46:21 -0800 Subject: [ python-Bugs-1597011 ] Reading with bz2.BZ2File() returns one garbage character Message-ID: Bugs item #1597011, was opened at 2006-11-15 12:19 Message generated for change (Comment added) made by cpn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597011&group_id=5470 Please note that this 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: 7 Private: No Submitted By: Clodoaldo Pinto Neto (cpn) Assigned to: Nobody/Anonymous (nobody) Summary: Reading with bz2.BZ2File() returns one garbage character Initial Comment: When comparing two files which should be equal the last line is different: The first file is a bzip2 compressed file and is read with bz2.BZ2File() The second file is the same file uncompressed and read with open() The first file named file.txt.bz2 is uncompressed with: $ bunzip2 -k file.txt.bz2 To compare I use this script: ############################### import bz2 f1 = bz2.BZ2File(r'file.txt.bz2', 'r') f2 = open(r'file.txt', 'r') lines = 0 while True: line1 = f1.readline() line2 = f2.readline() if line1 == '': break lines += 1 if line1 != line2: print 'line number:', lines print repr(line1) print repr(line2) f1.close() f2.close() ############################## Output: $ python bzp.py line number: 588317 '\x07' '' The offending attached file is 5.5 MB. Sorry, i could not reproduce this problem with a smaller file. Tested in Fedora Core 5 and Python 2.4.3 ---------------------------------------------------------------------- >Comment By: Clodoaldo Pinto Neto (cpn) Date: 2006-11-15 15:46 Message: Logged In: YES user_id=1646083 Originator: YES I received this file already compressed. I don't know what was the used compressor. There is no error if i test the compressed file with: $ bzip2 -t file.txt.bz2 ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-15 15:30 Message: Logged In: YES user_id=849994 Originator: NO With your file, I can reproduce that on Linux, Python 2.5. Which compressor did you compress your file with? I unpacked it with bunzip2 without problems, then recompressed it with bzip2, which resulted in a slightly smaller (51 bytes) file, which then didn't trigger the bug. ---------------------------------------------------------------------- Comment By: Clodoaldo Pinto Neto (cpn) Date: 2006-11-15 12:35 Message: Logged In: YES user_id=1646083 Originator: YES Confirmed in Windows Python 2.4 and 2.5 http://groups.google.com/group/comp.lang.python/tree/browse_frm/thread/3010fd664d78010f/4166d429b25c9ed4?rnum=1&_done=%2Fgroup%2Fcomp.lang.python%2Fbrowse_frm%2Fthread%2F3010fd664d78010f%2F4166d429b25c9ed4%3Ftvc%3D1%26#doc_7770aa47861db452 ---------------------------------------------------------------------- Comment By: Clodoaldo Pinto Neto (cpn) Date: 2006-11-15 12:28 Message: Logged In: YES user_id=1646083 Originator: YES I can't upload the bz2 sample file. So it is here: http://fahstats.com/img/file.txt.bz2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597011&group_id=5470 From noreply at sourceforge.net Wed Nov 15 19:51:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Nov 2006 10:51:50 -0800 Subject: [ python-Bugs-1596321 ] KeyError at exit after 'import threading' in other thread Message-ID: Bugs item #1596321, was opened at 2006-11-14 06:02 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1596321&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Threads Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Walther (cwalther) Assigned to: Nobody/Anonymous (nobody) Summary: KeyError at exit after 'import threading' in other thread Initial Comment: Python 2.4.3 on Windows 2000, though the code in question seems unchanged in current SVN (r46919). I'm using Python embedded in a multithreaded C++ application. When 'import threading' is first done in some Python script that runs in thread A, I get the following exception when a different thread B calls Py_Finalize(): Error in atexit._run_exitfuncs: Traceback (most recent call last): File "C:\Python24\lib\atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "C:\Python24\lib\threading.py", line 636, in __exitfunc self._Thread__delete() File "C:\Python24\lib\threading.py", line 522, in __delete del _active[_get_ident()] KeyError: 680 Error in sys.exitfunc: Traceback (most recent call last): File "C:\Python24\lib\atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "C:\Python24\lib\threading.py", line 636, in __exitfunc self._Thread__delete() File "C:\Python24\lib\threading.py", line 522, in __delete del _active[_get_ident()] KeyError: 680 The reason seems to be that the threading module uses the thread ID of the calling thread as a key to store its _MainThread instance on initialization, and again the thread ID of the calling thread to delete it in its exit function. If these two threads are not the same, the described KeyError occurs. I didn't study this in all detail, but it seems to me that threading.Thread.__delete() does the wrong thing. By doing 'del _active[_get_ident()]', it removes the instance for the calling thread from the _active dictionary. What it should be doing is removing *self* from that dictionary. Is that correct? ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-11-15 10:51 Message: Logged In: YES user_id=357491 Originator: NO Thanks for the test code. I have no clue when I or anyone else will get to this, but the report and testing code is appreciated. ---------------------------------------------------------------------- Comment By: Christian Walther (cwalther) Date: 2006-11-14 23:02 Message: Logged In: YES user_id=1061789 Originator: YES I'm not calling Py_Finalize from a non-main thread. What I called "thread B" is the main thread. It's the script that first imports the threading module that runs in a non-main thread (and running user-defined scripts in non-main threads is hopefully not unsafe, or there wouldn't be much point in supporting multithreading at all in Python). It didn't even occur to me that this could be reproduced in pure Python code, so I didn't include an example in my original post. Of course, it can - see attachment. Tested on Python 2.3.5 on Mac OS X. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-11-14 13:59 Message: Logged In: YES user_id=357491 Originator: NO Well, I don't think you should be calling Py_Finalize() from the non-main thread. That just seems unsafe to me. Regardless, though, could you write up some quick Python code that triggers this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1596321&group_id=5470 From noreply at sourceforge.net Wed Nov 15 21:59:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Nov 2006 12:59:02 -0800 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-23 02:07 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 Please note that this 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 Private: No Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-15 21:59 Message: Logged In: YES user_id=21627 Originator: NO What gcc version is this? In older versions, you have to do gcc -v -c empty.c and watch the verbose output. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-15 14:36 Message: Logged In: YES user_id=11105 Originator: NO Yes ;-), although I would have expected that 'gcc -E -dD empty.c' would have printed something. Does 'touch empty.c; cpp -dM empty.c' print something? ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-15 14:00 Message: Logged In: YES user_id=1645242 Originator: NO Something like this? ~ $ touch empty.c ~ $ gcc -E -dD empty.c # 1 "empty.c" ~ $ cat empty.c ~ $ ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-15 11:05 Message: Logged In: YES user_id=11105 Originator: NO memotype, can you please do what loewis suggested and report back: > Please compile an empty file with "gcc -E -dD empty.c" to find out what > defines are builtin. It is very likely that the symbol we need is a builtin symbol of the compiler, and not a symbol defined in some of the header files. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 20:29 Message: Logged In: YES user_id=1645242 Originator: NO Ohh, and before you ask (I forgot to mention): grepping for "ppc" (with -i) doesn't yield any more results. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 20:25 Message: Logged In: YES user_id=1645242 Originator: NO I'm sorry, I meant __ppc__, it was the __ppc__ lines that I removed. As for PPC specific defines, I can't find any that work, but grepping around in /usr/include shows: /usr/include $ grep -i powerpc * aouthdr.h: * Defines for the POWER and PowerPC CPU Types aouthdr.h:#define TCPU_PPC 1 /* PowerPC common architecture 32 bit mode */ aouthdr.h:#define TCPU_PPC64 2 /* PowerPC common architecture 64 bit mode */ aouthdr.h:#define TCPU_COM 3 /* POWER and PowerPC architecture common */ aouthdr.h: /* and PowerPC architecture implementations */ aouthdr.h:#define TCPU_601 6 /* 601 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_603 7 /* 603 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_604 8 /* 604 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_620 16 /* 620 implementation of PowerPC 64-bit architecture */ aouthdr.h:#define TCPU_A35 17 /* A35 implementation of PowerPC 64-bit architecture */ filehdr.h:/* IBM POWER and PowerPC */ frs.h:| - rom_scan_R2_6002_block_t (PowerPC devices) frs.h:| - rom_scan_R2_6003_block_t (60x PowerPC devices) frs.h:| The PowerPC 601 Bus has such characteristics. frs.h:| that matches the PowerPC 60X Bus and PowerPC System Architecture frs_60x.h: | as defined by PowerPC System ARch and unique frs_60x.h:| PowerPC Feature/VPD Header reloc.h: * POWER and PowerPC - relocation types I would love to send you a copy of the aouthdr.h, but I'm not sure if that would violate any licenses, so I will have to leave the rest to you guys to look for some definitive documentation as to how to detect ppc from defines. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-14 20:08 Message: Logged In: YES user_id=21627 Originator: NO Please compile an empty file with "gcc -E -dD empty.c" to find out what defines are builtin. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 19:47 Message: Logged In: YES user_id=11105 Originator: NO Hm, I was asking for '__ppc__', not '__aix__'. Can you look for processor specific defines, please? ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 19:35 Message: Logged In: YES user_id=1645242 Originator: NO _AIX however, /is/ defined, so maybe s/__aix__/_AIX/g? ~/Python-2.5 $ cat <<. > test.c > int main() { > #ifdef _AIX > return 0; > #endif > #ifndef _AIX > return 1; > #endif > } > . ~/Python-2.5 $ gcc -o test test.c ~/Python-2.5 $ ./test ~/Python-2.5 $ echo $? 0 ~/Python-2.5 $ ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 19:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 19:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 18:05 Message: Logged In: YES user_id=11105 Well, there is certainly a diff in noctypes.diff. If your patch program cannot handle it, you may want to apply it manually (basically you have to remove/comment out two sections of code in setup.py). It seems that there are actually two bugs: 1. setup.py doesn't continue after trying to import the _ctypes extension. No idea why, but somewhere something exists the process. 2. _ctypes.so does not build (or better fails to load) because of missing symbols: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN I have no access to an AIX system, do I cannot try this out myself. One thing that comes to mind: These functions are implemented in the file Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c. This file is compiled, without errors. One problem could be that the whole file contents are included in an #ifdef block like this: #ifdef __ppc__ ... #endif Can it be that __ppc__ is not defined on this system? Can someone try out to build with these two lines removed? Thanks. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 16:55 Message: Logged In: YES user_id=1645242 What is the status on this bug? I tried the work around, but patch doesn't like the diff file provided, says "Processing... I cannot find a patch in there anywhere." ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:55 Message: Logged In: YES user_id=129055 Build finished running; full log attached as python-2.5- ctypes.log.gz. Relevent lines are: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep [... more ld errors ...] collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 And at this point gmake exits and the build stops. Running gmake again just causes the same error to pop up. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:29 Message: Logged In: YES user_id=129055 Ah, well there is a bug then... setup.py does not continue on its own. I've added an attachement of a successful full build log (built with the noctypes patch), and will attach a second full build log that shows the build failing on the error when it finishes running in 10-20 minutes... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 14:14 Message: Logged In: YES user_id=21627 No; setup.py should continue on its own. If it doesn't, that's a bug. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:06 Message: Logged In: YES user_id=129055 loewis: No, the ctypes error messages cause the build to fail. Are you saying to use "gmake -k" or something like that? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 13:15 Message: Logged In: YES user_id=21627 You don't need to disable it. It will print error messages, but you can just ignore them if you don't need the ctypes module. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 05:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 04:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 02:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Wed Nov 15 22:15:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Nov 2006 13:15:24 -0800 Subject: [ python-Bugs-1592241 ] Stepping into a generator throw does not work Message-ID: Bugs item #1592241, was opened at 2006-11-07 12:05 Message generated for change (Comment added) made by bwmulder You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1592241&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Bernhard Mulder (bwmulder) Assigned to: Nobody/Anonymous (nobody) Summary: Stepping into a generator throw does not work Initial Comment: Python version: 2.6 Platform: Windows XP Stepping into a throw of an iterator with the debugger does not work. To reproduce: 1. Run the attached script 2. type 's' for single step once you see the debugger prompt. I am getting this backtrace: File "C:\bwm\Cruiser\play\microthreads\post.py", line 24, in it.throw(E, E()) File "C:\bwm\Cruiser\play\microthreads\post.py", line 7, in f1 (yield (2,(self.f2,(exc_class,)))) File "C:\Python25\lib\bdb.py", line 50, in trace_dispatch return self.dispatch_call(frame, arg) File "C:\Python25\lib\bdb.py", line 79, in dispatch_call self.user_call(frame, arg) File "C:\Python25\lib\pdb.py", line 134, in user_call self.interaction(frame, None) File "C:\Python25\lib\pdb.py", line 185, in interaction self.setup(frame, traceback) File "C:\Python25\lib\pdb.py", line 109, in setup self.stack, self.curindex = self.get_stack(f, t) File "C:\Python25\lib\bdb.py", line 318, in get_stack i = max(0, len(stack) - 1) ---------------------------------------------------------------------- >Comment By: Bernhard Mulder (bwmulder) Date: 2006-11-15 13:15 Message: Logged In: YES user_id=580676 Originator: YES I got the Python version wrong above. The problem has been observed with Python 2.5, not 2.6 (don't know about other Python versions). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1592241&group_id=5470 From noreply at sourceforge.net Thu Nov 16 02:00:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Nov 2006 17:00:08 -0800 Subject: [ python-Bugs-1597404 ] sqlite timestamp converter bug (floating point) Message-ID: Bugs item #1597404, was opened at 2006-11-15 20: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=1597404&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Michael Salib (msalib_ita) Assigned to: Nobody/Anonymous (nobody) Summary: sqlite timestamp converter bug (floating point) Initial Comment: The pysqlite code in Python 2.5 has a bug. This bug also exists in the upstream pysqlite2 release, but their tracker is down so I cannot submit it there. The bug is as follows: if you insert a datetime object into a sqlite database and then try to retrieve the object, you will (in some cases) get a datetime instance with a slightly smaller value for the microseconds field. This bug occurs because pysqlite is doing pointless floating point conversions. I describe two fixes and an extra test case below. This bug is real. I have observed it in the wild. The test set for my application can trigger this bug about once every 20 runs. This is what happens: * pysqlite includes an adapter and converter function so that datetime objects can transparently be inserted and retrieved from a sqlite database column of type timestamp. * When inserting a datetime object, pysqlite's adapter will insert the isoformat() value of the object. * When retrieving, pysqlite will take the iso formatted string representation of the datetime object and convert it into an actual datetime object. This conversion is buggy. * Check out line 71 of Lib/sqlite3/dbapi2.py. The code is: microseconds = int(float("0." + timepart_full[1]) * 1000000) And that is where the bug is. This code takes an integer value, converts it into a float (implicitly dividing by 1000000, then multiplies that by 1000000 and takes the integer part. For most values, that process gives the result you expect. For some values however, like 510241, that process gives slightly smaller values because of floating point rounding. There are two possible fixes: 1. The simple fix is to just do rounding properly by using this line in place of the previous line: microseconds = int(0.5 + (float("0." + timepart_full[1]) * 1000000)) This will eliminate the bug. 2. The better fix (IMHO) is to stop playing games with floating point numbers. There is absolutely no reason to introduce floats into this computation. The datetime object stores microseconds as an integer value and it gets written to the database as a stringified integer value. Taking apart that string and converting it into an integer is a lossless operation. My preferred fix is thus: microseconds = int(timepart_full[1]) This will eliminate the bug and it has the benefit of being shorter as well. I've attached a patch with my preferred fix as well as an extra test in the pysqlite test suite (Lib/sqlite3/test/types.py). You can run the pysqlite test suite by running Lib/sqlite3/test/types.py. Note that without my fix, the test that I added (DateTimeTests.CheckDateTimeSubSecondsFloatingPoint) will fail but with my fix it will pass. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597404&group_id=5470 From noreply at sourceforge.net Thu Nov 16 07:18:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 15 Nov 2006 22:18:39 -0800 Subject: [ python-Bugs-1597404 ] sqlite timestamp converter bug (floating point) Message-ID: Bugs item #1597404, was opened at 2006-11-16 02:00 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597404&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Michael Salib (msalib_ita) >Assigned to: Gerhard H?ring (ghaering) Summary: sqlite timestamp converter bug (floating point) Initial Comment: The pysqlite code in Python 2.5 has a bug. This bug also exists in the upstream pysqlite2 release, but their tracker is down so I cannot submit it there. The bug is as follows: if you insert a datetime object into a sqlite database and then try to retrieve the object, you will (in some cases) get a datetime instance with a slightly smaller value for the microseconds field. This bug occurs because pysqlite is doing pointless floating point conversions. I describe two fixes and an extra test case below. This bug is real. I have observed it in the wild. The test set for my application can trigger this bug about once every 20 runs. This is what happens: * pysqlite includes an adapter and converter function so that datetime objects can transparently be inserted and retrieved from a sqlite database column of type timestamp. * When inserting a datetime object, pysqlite's adapter will insert the isoformat() value of the object. * When retrieving, pysqlite will take the iso formatted string representation of the datetime object and convert it into an actual datetime object. This conversion is buggy. * Check out line 71 of Lib/sqlite3/dbapi2.py. The code is: microseconds = int(float("0." + timepart_full[1]) * 1000000) And that is where the bug is. This code takes an integer value, converts it into a float (implicitly dividing by 1000000, then multiplies that by 1000000 and takes the integer part. For most values, that process gives the result you expect. For some values however, like 510241, that process gives slightly smaller values because of floating point rounding. There are two possible fixes: 1. The simple fix is to just do rounding properly by using this line in place of the previous line: microseconds = int(0.5 + (float("0." + timepart_full[1]) * 1000000)) This will eliminate the bug. 2. The better fix (IMHO) is to stop playing games with floating point numbers. There is absolutely no reason to introduce floats into this computation. The datetime object stores microseconds as an integer value and it gets written to the database as a stringified integer value. Taking apart that string and converting it into an integer is a lossless operation. My preferred fix is thus: microseconds = int(timepart_full[1]) This will eliminate the bug and it has the benefit of being shorter as well. I've attached a patch with my preferred fix as well as an extra test in the pysqlite test suite (Lib/sqlite3/test/types.py). You can run the pysqlite test suite by running Lib/sqlite3/test/types.py. Note that without my fix, the test that I added (DateTimeTests.CheckDateTimeSubSecondsFloatingPoint) will fail but with my fix it will pass. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-16 07:18 Message: Logged In: YES user_id=21627 Originator: NO Gerhard, can you please take a look? If not, unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597404&group_id=5470 From noreply at sourceforge.net Thu Nov 16 10:19:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 01:19:52 -0800 Subject: [ python-Bugs-1597570 ] "Report website bug" -> Forbidden :( Message-ID: Bugs item #1597570, was opened at 2006-11-16 10: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=1597570&group_id=5470 Please note that this 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: Not a Bug Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jens Diemer (pylucid) Assigned to: Nobody/Anonymous (nobody) Summary: "Report website bug" -> Forbidden :( Initial Comment: I would report a enhancement for the python.org site. But if i go to http://pydotorg.python.org/pydotorg/newticket i see only: """ Forbidden TICKET_CREATE privileges are required to perform this operation """ :( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597570&group_id=5470 From noreply at sourceforge.net Thu Nov 16 10:25:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 01:25:23 -0800 Subject: [ python-Feature Requests-1597576 ] base64 doc Python 2.3 <-> 2.4 Message-ID: Feature Requests item #1597576, was opened at 2006-11-16 10:25 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=1597576&group_id=5470 Please note that this 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 Private: No Submitted By: Jens Diemer (pylucid) Assigned to: Nobody/Anonymous (nobody) Summary: base64 doc Python 2.3 <-> 2.4 Initial Comment: Because of the Bug here: http://sourceforge.net/tracker/index.php?func=detail&aid=1597570&group_id=5470&atid=105470 i can't report it into the new python.org trac :( ----------------------------------------------------- The base64 doc does not mention, which function is new in Python 2.4.x I have try to use b64encode with Python 2.3 :) Please compare: http://www.python.org/doc/2.3.5/lib/module-base64.html with: http://www.python.org/doc/2.4.2/lib/module-base64.html and http://docs.python.org/lib/module-base64.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1597576&group_id=5470 From noreply at sourceforge.net Thu Nov 16 16:06:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 07:06:13 -0800 Subject: [ python-Feature Requests-1597576 ] base64 doc Python 2.3 <-> 2.4 Message-ID: Feature Requests item #1597576, was opened at 2006-11-16 09:25 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1597576&group_id=5470 Please note that this 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 Private: No Submitted By: Jens Diemer (pylucid) Assigned to: Nobody/Anonymous (nobody) Summary: base64 doc Python 2.3 <-> 2.4 Initial Comment: Because of the Bug here: http://sourceforge.net/tracker/index.php?func=detail&aid=1597570&group_id=5470&atid=105470 i can't report it into the new python.org trac :( ----------------------------------------------------- The base64 doc does not mention, which function is new in Python 2.4.x I have try to use b64encode with Python 2.3 :) Please compare: http://www.python.org/doc/2.3.5/lib/module-base64.html with: http://www.python.org/doc/2.4.2/lib/module-base64.html and http://docs.python.org/lib/module-base64.html ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-16 15:06 Message: Logged In: YES user_id=849994 Originator: NO This should have been classified as a bug, and reported here in any case, since the documentation is part of the sources, not the website. That aside, it's now fixed in rev. 52762, 52763 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1597576&group_id=5470 From noreply at sourceforge.net Thu Nov 16 16:07:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 07:07:30 -0800 Subject: [ python-Bugs-1597570 ] "Report website bug" -> Forbidden :( Message-ID: Bugs item #1597570, was opened at 2006-11-16 09:19 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597570&group_id=5470 Please note that this 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: Not a Bug >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Jens Diemer (pylucid) Assigned to: Nobody/Anonymous (nobody) Summary: "Report website bug" -> Forbidden :( Initial Comment: I would report a enhancement for the python.org site. But if i go to http://pydotorg.python.org/pydotorg/newticket i see only: """ Forbidden TICKET_CREATE privileges are required to perform this operation """ :( ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-16 15:07 Message: Logged In: YES user_id=849994 Originator: NO The pydotorg requires registration, which is boldly pointed out on the wiki page that the "report website bug" link refers to. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597570&group_id=5470 From noreply at sourceforge.net Thu Nov 16 16:37:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 07:37:41 -0800 Subject: [ python-Bugs-1597798 ] Modules/readline.c fails to compile on AIX 4.2 Message-ID: Bugs item #1597798, was opened at 2006-11-16 10: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=1597798&group_id=5470 Please note that this 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 Private: No Submitted By: Mike Kent (mikekent) Assigned to: Nobody/Anonymous (nobody) Summary: Modules/readline.c fails to compile on AIX 4.2 Initial Comment: Python 2.5 Modules/readline.c line 681 is: return completion_matches(text, *on_completion); on_completion is a function declared as: static char *on_completion(char *text, int state); completion_matches is a macro that expands to: rl_completion_matches((x), ((rl_compentry_func_t *)(y))) SO, the second parameter to completion_matches should be a function pointer (on_completion), not the dereferenced function pointer that is currently passed to it (*on_completion). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597798&group_id=5470 From noreply at sourceforge.net Thu Nov 16 17:23:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 08:23:32 -0800 Subject: [ python-Bugs-1597824 ] atexit.register does not return the registered function. Message-ID: Bugs item #1597824, was opened at 2006-11-16 16: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=1597824&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Pierre Rouleau (pierre_rouleau) Assigned to: Nobody/Anonymous (nobody) Summary: atexit.register does not return the registered function. Initial Comment: Since that the decorator syntax is upon us, I think it would be good if atexit.register() was returning the function passed as argument. This simple change to the library would solve a problem with the use of atexit.register as a decorator (and I can't think of any use case where this change would break any code). I describe the problem in the following text:: Problem using atexit.register as a decorator ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In his April 2005 article titled `Python 2.4 Decorators: Reducing code duplication and consolidating knowledge`_ , Phillip Eby describes how you can use `atexit.register()`_ from the standard Python library. He shows how to use the decorator syntax to register a function that will execute at program termination. Here is how it goes:: @atexit.register def goodbye(): print "Goodbye, terminating..." However, there is one fundamental problem with this: atexit.register() returns None. Since the above code corresponds to:: def goodbye(): print "Goodbye, terminating..." goodbye = atexit.register(goodbye) the code registers goodbye but right after it binds goodbye to None! You can see this in the following session:: >>> import atexit >>> @atexit.register ... def goodbye(): ... print "Goodbye, terminating..." ... >>> goodbye() Traceback (most recent call last): File "", line 1, in ? TypeError: 'NoneType' object is not callable >>> >>> goodbye >>> type(goodbye) >>> There is two solutions to this problem: 1. Use another function to register and decorate. 2. Change atexit.register() in the Python library so that it returns the function it registers. Solution 1 can be implemented right away:: def atexit_register(fct): atexit.register(fct) return fct @atexit_register def goodbye2(): print "Goodbye 2!!" and it works: it registers the function for execution at termination but leaves goodbye2 callable:: >>> def atexit_register(fct): ... atexit.register(fct) ... return fct ... >>> @atexit_register ... def goodbye2(): ... print "Goodbye 2!!" ... >>> goodbye2() Goodbye 2!! >>> goodbye2 >>> .. References .. _atexit.register(): http://www.python.org/doc/current/lib/module-atexit.html .. _Python 2.4 Decorators\: Reducing code duplication and consolidating knowledge: http://www.ddj.com/184406073 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597824&group_id=5470 From noreply at sourceforge.net Thu Nov 16 17:52:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 08:52:16 -0800 Subject: [ python-Bugs-1597824 ] atexit.register does not return the registered function. Message-ID: Bugs item #1597824, was opened at 2006-11-16 16:23 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597824&group_id=5470 Please note that this message will contain 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: Accepted Priority: 5 Private: No Submitted By: Pierre Rouleau (pierre_rouleau) >Assigned to: Georg Brandl (gbrandl) Summary: atexit.register does not return the registered function. Initial Comment: Since that the decorator syntax is upon us, I think it would be good if atexit.register() was returning the function passed as argument. This simple change to the library would solve a problem with the use of atexit.register as a decorator (and I can't think of any use case where this change would break any code). I describe the problem in the following text:: Problem using atexit.register as a decorator ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ In his April 2005 article titled `Python 2.4 Decorators: Reducing code duplication and consolidating knowledge`_ , Phillip Eby describes how you can use `atexit.register()`_ from the standard Python library. He shows how to use the decorator syntax to register a function that will execute at program termination. Here is how it goes:: @atexit.register def goodbye(): print "Goodbye, terminating..." However, there is one fundamental problem with this: atexit.register() returns None. Since the above code corresponds to:: def goodbye(): print "Goodbye, terminating..." goodbye = atexit.register(goodbye) the code registers goodbye but right after it binds goodbye to None! You can see this in the following session:: >>> import atexit >>> @atexit.register ... def goodbye(): ... print "Goodbye, terminating..." ... >>> goodbye() Traceback (most recent call last): File "", line 1, in ? TypeError: 'NoneType' object is not callable >>> >>> goodbye >>> type(goodbye) >>> There is two solutions to this problem: 1. Use another function to register and decorate. 2. Change atexit.register() in the Python library so that it returns the function it registers. Solution 1 can be implemented right away:: def atexit_register(fct): atexit.register(fct) return fct @atexit_register def goodbye2(): print "Goodbye 2!!" and it works: it registers the function for execution at termination but leaves goodbye2 callable:: >>> def atexit_register(fct): ... atexit.register(fct) ... return fct ... >>> @atexit_register ... def goodbye2(): ... print "Goodbye 2!!" ... >>> goodbye2() Goodbye 2!! >>> goodbye2 >>> .. References .. _atexit.register(): http://www.python.org/doc/current/lib/module-atexit.html .. _Python 2.4 Decorators\: Reducing code duplication and consolidating knowledge: http://www.ddj.com/184406073 ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-16 16:52 Message: Logged In: YES user_id=849994 Originator: NO This is a reasonable request, I changed atexit.register in rev. 52764 for 2.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597824&group_id=5470 From noreply at sourceforge.net Thu Nov 16 18:09:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 09:09:14 -0800 Subject: [ python-Bugs-1588217 ] quoted printable parse the sequence '= ' incorrectly Message-ID: Bugs item #1588217, was opened at 2006-10-31 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=1588217&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Wai Yip Tung (tungwaiyip) >Assigned to: Georg Brandl (gbrandl) Summary: quoted printable parse the sequence '= ' incorrectly Initial Comment: >>> import quopri >>> s = 'I say= a secret message\r\nThank you' >>> quopri.a2b_qp >>> quopri.decodestring(s) # use the c version binascii.a2b_qp() to decode 'I sayThank you' >>> quopri.a2b_qp=None >>> quopri.decodestring(s) # use the python version quopri.decode() to decode 'I say= a secret message\nThank you' Note that the sequence '= ' is invalid according to RFC 2045 section 6.7: ------------------------------------------------------- An "=" followed by a character that is neither a hexadecimal digit (including "abcdef") nor the CR character of a CRLF pair is illegal ... A reasonable approach by a robust implementation might be to include the "=" character and the following character in the decoded data without any transformation ------------------------------------------------------- The lenient interpretation is used by the Python version parser quopri.decode() to produce the second string. Most email clients use a similar lenient interpretation. The C version parser binascii.a2b_qp(), which is used in preference to the Python verison, produce a surprising result with the string 'a secret message' omitted. This may create an opportunity for spammers to insert secret message after '= ' so that it is not visible to Python based spam filter but woiuld display in non- Python based email client. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-16 17:09 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the report, this is now fixed in rev. 52765, 52766 (2.5). ---------------------------------------------------------------------- Comment By: Wai Yip Tung (tungwaiyip) Date: 2006-10-31 21:18 Message: Logged In: YES user_id=561546 The problem may come from binascii_a2b_qp() in binascii.c. It considers the '= ' or '=\t' sequence as a soft line break. Such interpretation appears to have no basis. It could be an misinterpretation of RFC 2045: ------------------------------------------------------------------- In particular, an "=" at the end of an encoded line, indicating a soft line break (see rule #5) may follow one or more TAB (HT) or SPACE characters. ------------------------------------------------------------------- This passage reminds readers they might find TAB or SPACE before an "=", but not after it. "= " is plain illegal as far as I know. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1588217&group_id=5470 From noreply at sourceforge.net Thu Nov 16 19:40:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 10:40:46 -0800 Subject: [ python-Bugs-1597930 ] Python/ast.c:541: seq_for_testlist: Assertion fails Message-ID: Bugs item #1597930, was opened at 2006-11-16 13:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597930&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Darrell Schiebel (schiebel) Assigned to: Nobody/Anonymous (nobody) Summary: Python/ast.c:541: seq_for_testlist: Assertion fails Initial Comment: As per bug #1588287, under rhel4 python 2.5 cannot build numpy-1.0 unless the assert()s are turned off. Attached is a log file of my build attempt which basically consisted of: cd Python-2.5 ./configure make OPT=-g cd numpy-1.0 ../python setup.py build This fails with this error: python: Python/ast.c:541: seq_for_testlist: Assertion `((n)->n_type) == 326 || ((n)->n_type) == 318 || ((n)->n_type) == 319 || ((n)->n_type) == \ 300' failed. While I'm reluctant to just #ifdef out the asserts() [by defining -DNDEBUG on the compile line], this clearly must be why other people haven't run into this. thanks, Darrell ps: the Python-2.5.tar.bz2 & numpy-1.0.tar.gz files are just the public source tarballs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597930&group_id=5470 From noreply at sourceforge.net Thu Nov 16 19:47:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 10:47:32 -0800 Subject: [ python-Bugs-1597930 ] Python/ast.c:541: seq_for_testlist: Assertion fails Message-ID: Bugs item #1597930, was opened at 2006-11-16 18:40 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597930&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Darrell Schiebel (schiebel) Assigned to: Nobody/Anonymous (nobody) Summary: Python/ast.c:541: seq_for_testlist: Assertion fails Initial Comment: As per bug #1588287, under rhel4 python 2.5 cannot build numpy-1.0 unless the assert()s are turned off. Attached is a log file of my build attempt which basically consisted of: cd Python-2.5 ./configure make OPT=-g cd numpy-1.0 ../python setup.py build This fails with this error: python: Python/ast.c:541: seq_for_testlist: Assertion `((n)->n_type) == 326 || ((n)->n_type) == 318 || ((n)->n_type) == 319 || ((n)->n_type) == \ 300' failed. While I'm reluctant to just #ifdef out the asserts() [by defining -DNDEBUG on the compile line], this clearly must be why other people haven't run into this. thanks, Darrell ps: the Python-2.5.tar.bz2 & numpy-1.0.tar.gz files are just the public source tarballs. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-16 18:47 Message: Logged In: YES user_id=849994 Originator: NO This was already fixed with bug #1588287, bug thanks for reporting it nevertheless. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597930&group_id=5470 From noreply at sourceforge.net Thu Nov 16 20:22:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 11:22:08 -0800 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-22 20:07 Message generated for change (Comment added) made by memotype You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 Please note that this 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 Private: No Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-16 14:22 Message: Logged In: YES user_id=1645242 Originator: NO /home/rvjif00 $ gcc --version 2.9-aix51-020209 /home/rvjif00 $ gcc -v -c empty.c Reading specs from /opt/freeware/GNUPro/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/specs gcc version 2.9-aix51-020209 /opt/freeware/GNUPro/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/cpp -lang-c -v -iprefix /bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/ -D__GNUC__=2 -D__GNUC_MINOR__=9 -D_IBMR2 -D_POWER -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 -D_AIX51 -D_LONG_LONG -D_IBMR2 -D_POWER -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 -D_AIX51 -D_LONG_LONG -Asystem(unix) -Asystem(aix) -D__CHAR_UNSIGNED__ -D_ARCH_COM empty.c /tmp/ccTtoObS.i GNU CPP version 2.9-aix51-020209 #include "..." search starts here: #include <...> search starts here: /opt/freeware/GNUPro/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/include /usr/include End of search list. The following default directories have been omitted from the search path: /opt/freeware/GNUPro/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/../../../../include/g++-3 /opt/freeware/GNUPro/include /opt/freeware/GNUPro/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/../../../../powerpc-ibm-aix5.1.0.0/include End of omitted list. /opt/freeware/GNUPro/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/cc1 /tmp/ccTtoObS.i -quiet -dumpbase empty.c -version -o /tmp/cc28GcTD.s GNU C version 2.9-aix51-020209 (powerpc-ibm-aix5.1.0.0) compiled by GNU C version 2.9-aix51-020209. as -u -mcom -o empty.o /tmp/cc28GcTD.s ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-15 15:59 Message: Logged In: YES user_id=21627 Originator: NO What gcc version is this? In older versions, you have to do gcc -v -c empty.c and watch the verbose output. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-15 08:36 Message: Logged In: YES user_id=11105 Originator: NO Yes ;-), although I would have expected that 'gcc -E -dD empty.c' would have printed something. Does 'touch empty.c; cpp -dM empty.c' print something? ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-15 08:00 Message: Logged In: YES user_id=1645242 Originator: NO Something like this? ~ $ touch empty.c ~ $ gcc -E -dD empty.c # 1 "empty.c" ~ $ cat empty.c ~ $ ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-15 05:05 Message: Logged In: YES user_id=11105 Originator: NO memotype, can you please do what loewis suggested and report back: > Please compile an empty file with "gcc -E -dD empty.c" to find out what > defines are builtin. It is very likely that the symbol we need is a builtin symbol of the compiler, and not a symbol defined in some of the header files. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 14:29 Message: Logged In: YES user_id=1645242 Originator: NO Ohh, and before you ask (I forgot to mention): grepping for "ppc" (with -i) doesn't yield any more results. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 14:25 Message: Logged In: YES user_id=1645242 Originator: NO I'm sorry, I meant __ppc__, it was the __ppc__ lines that I removed. As for PPC specific defines, I can't find any that work, but grepping around in /usr/include shows: /usr/include $ grep -i powerpc * aouthdr.h: * Defines for the POWER and PowerPC CPU Types aouthdr.h:#define TCPU_PPC 1 /* PowerPC common architecture 32 bit mode */ aouthdr.h:#define TCPU_PPC64 2 /* PowerPC common architecture 64 bit mode */ aouthdr.h:#define TCPU_COM 3 /* POWER and PowerPC architecture common */ aouthdr.h: /* and PowerPC architecture implementations */ aouthdr.h:#define TCPU_601 6 /* 601 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_603 7 /* 603 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_604 8 /* 604 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_620 16 /* 620 implementation of PowerPC 64-bit architecture */ aouthdr.h:#define TCPU_A35 17 /* A35 implementation of PowerPC 64-bit architecture */ filehdr.h:/* IBM POWER and PowerPC */ frs.h:| - rom_scan_R2_6002_block_t (PowerPC devices) frs.h:| - rom_scan_R2_6003_block_t (60x PowerPC devices) frs.h:| The PowerPC 601 Bus has such characteristics. frs.h:| that matches the PowerPC 60X Bus and PowerPC System Architecture frs_60x.h: | as defined by PowerPC System ARch and unique frs_60x.h:| PowerPC Feature/VPD Header reloc.h: * POWER and PowerPC - relocation types I would love to send you a copy of the aouthdr.h, but I'm not sure if that would violate any licenses, so I will have to leave the rest to you guys to look for some definitive documentation as to how to detect ppc from defines. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-14 14:08 Message: Logged In: YES user_id=21627 Originator: NO Please compile an empty file with "gcc -E -dD empty.c" to find out what defines are builtin. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 13:47 Message: Logged In: YES user_id=11105 Originator: NO Hm, I was asking for '__ppc__', not '__aix__'. Can you look for processor specific defines, please? ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 13:35 Message: Logged In: YES user_id=1645242 Originator: NO _AIX however, /is/ defined, so maybe s/__aix__/_AIX/g? ~/Python-2.5 $ cat <<. > test.c > int main() { > #ifdef _AIX > return 0; > #endif > #ifndef _AIX > return 1; > #endif > } > . ~/Python-2.5 $ gcc -o test test.c ~/Python-2.5 $ ./test ~/Python-2.5 $ echo $? 0 ~/Python-2.5 $ ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 13:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 13:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 12:05 Message: Logged In: YES user_id=11105 Well, there is certainly a diff in noctypes.diff. If your patch program cannot handle it, you may want to apply it manually (basically you have to remove/comment out two sections of code in setup.py). It seems that there are actually two bugs: 1. setup.py doesn't continue after trying to import the _ctypes extension. No idea why, but somewhere something exists the process. 2. _ctypes.so does not build (or better fails to load) because of missing symbols: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN I have no access to an AIX system, do I cannot try this out myself. One thing that comes to mind: These functions are implemented in the file Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c. This file is compiled, without errors. One problem could be that the whole file contents are included in an #ifdef block like this: #ifdef __ppc__ ... #endif Can it be that __ppc__ is not defined on this system? Can someone try out to build with these two lines removed? Thanks. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 10:55 Message: Logged In: YES user_id=1645242 What is the status on this bug? I tried the work around, but patch doesn't like the diff file provided, says "Processing... I cannot find a patch in there anywhere." ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:55 Message: Logged In: YES user_id=129055 Build finished running; full log attached as python-2.5- ctypes.log.gz. Relevent lines are: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep [... more ld errors ...] collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 And at this point gmake exits and the build stops. Running gmake again just causes the same error to pop up. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:29 Message: Logged In: YES user_id=129055 Ah, well there is a bug then... setup.py does not continue on its own. I've added an attachement of a successful full build log (built with the noctypes patch), and will attach a second full build log that shows the build failing on the error when it finishes running in 10-20 minutes... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 08:14 Message: Logged In: YES user_id=21627 No; setup.py should continue on its own. If it doesn't, that's a bug. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 08:06 Message: Logged In: YES user_id=129055 loewis: No, the ctypes error messages cause the build to fail. Are you saying to use "gmake -k" or something like that? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 07:15 Message: Logged In: YES user_id=21627 You don't need to disable it. It will print error messages, but you can just ignore them if you don't need the ctypes module. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 23:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 22:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-22 20:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Fri Nov 17 00:50:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 15:50:10 -0800 Subject: [ python-Bugs-1598083 ] Top-level exception handler writes to stdout unsafely Message-ID: Bugs item #1598083, was opened at 2006-11-16 18: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=1598083&group_id=5470 Please note that this message 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 Private: No Submitted By: Jp Calderone (kuran) Assigned to: Nobody/Anonymous (nobody) Summary: Top-level exception handler writes to stdout unsafely Initial Comment: When an exception reaches the top frame and is displayed by the exception handler, they are handled by formatting them to stderr. This involves a series of calls to PyFile_WriteString, either directly from PyErr_Display or indirectly through PyTraceBack_Print. Few, if any, of these PyFile_WriteString calls have their result checked for error. Worse, PyFile_WriteString itself does not check the return value of fputs(). So, for example, with a signal handler installed, a signal received while a traceback is being printed can result in the traceback _not_ being printed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598083&group_id=5470 From noreply at sourceforge.net Fri Nov 17 04:28:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 19:28:15 -0800 Subject: [ python-Bugs-1595742 ] SocketServer allow_reuse_address checked in constructor Message-ID: Bugs item #1595742, was opened at 2006-11-13 11:54 Message generated for change (Comment added) made by parente You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595742&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Peter Parente (parente) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer allow_reuse_address checked in constructor Initial Comment: Python 2.4.3 (#1, Oct 1 2006, 18:00:19) [GCC 4.1.1 20060928 (Red Hat 4.1.1-28)] on linux2 The documentation in the SocketServer class indicates that the allow_reuse_address flag may be set on a SocketServer subclass *or instance.* However, the flag is read in a call to the server_bind() from the constructor of the server object. Therefore, setting the flag on a created instance has no effect. This is problematic when trying to set the flag on SimpleXMLRPCServer instances, for instance, which are often not subclassed. This flag should probably become one of the keyword arguments in the constructor of a SocketServer object. ---------------------------------------------------------------------- >Comment By: Peter Parente (parente) Date: 2006-11-16 22:28 Message: Logged In: YES user_id=624776 Originator: YES Will do. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-15 12:34 Message: Logged In: YES user_id=849994 Originator: NO Would you want to work on a patch for this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595742&group_id=5470 From noreply at sourceforge.net Fri Nov 17 06:50:53 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 21:50:53 -0800 Subject: [ python-Bugs-1598166 ] The empty set is a subset of the empty set Message-ID: Bugs item #1598166, was opened at 2006-11-17 00: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=1598166&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Andreas Kloeckner (inducer) Assigned to: Nobody/Anonymous (nobody) Summary: The empty set is a subset of the empty set Initial Comment: Python 2.4.4 (#2, Oct 20 2006, 00:23:25) [GCC 4.1.2 20061015 (prerelease) (Debian 4.1.1-16.1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> set([]) < set([1]) True >>> set([]) < set([]) False The last expression should evaluate to True to be mathematically correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598166&group_id=5470 From noreply at sourceforge.net Fri Nov 17 06:51:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 21:51:17 -0800 Subject: [ python-Bugs-1598166 ] The empty set should be a subset of the empty set Message-ID: Bugs item #1598166, was opened at 2006-11-17 00:50 Message generated for change (Settings changed) made by inducer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598166&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Andreas Kloeckner (inducer) Assigned to: Nobody/Anonymous (nobody) >Summary: The empty set should be a subset of the empty set Initial Comment: Python 2.4.4 (#2, Oct 20 2006, 00:23:25) [GCC 4.1.2 20061015 (prerelease) (Debian 4.1.1-16.1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> set([]) < set([1]) True >>> set([]) < set([]) False The last expression should evaluate to True to be mathematically correct. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598166&group_id=5470 From noreply at sourceforge.net Fri Nov 17 07:34:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 22:34:12 -0800 Subject: [ python-Bugs-1598166 ] The empty set should be a subset of the empty set Message-ID: Bugs item #1598166, was opened at 2006-11-17 05:50 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598166&group_id=5470 Please note that this message will contain 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: Works For Me Priority: 5 Private: No Submitted By: Andreas Kloeckner (inducer) Assigned to: Nobody/Anonymous (nobody) Summary: The empty set should be a subset of the empty set Initial Comment: Python 2.4.4 (#2, Oct 20 2006, 00:23:25) [GCC 4.1.2 20061015 (prerelease) (Debian 4.1.1-16.1)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> set([]) < set([1]) True >>> set([]) < set([]) False The last expression should evaluate to True to be mathematically correct. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-17 06:34 Message: Logged In: YES user_id=849994 Originator: NO To get the mathematical "subset or equal" operator, use "<=". "<" is "is a strict subset". Closing as "works for me". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598166&group_id=5470 From noreply at sourceforge.net Fri Nov 17 07:40:35 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 22:40:35 -0800 Subject: [ python-Bugs-1598181 ] subprocess.py: O(N**2) bottleneck Message-ID: Bugs item #1598181, was opened at 2006-11-16 22:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598181&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.py: O(N**2) bottleneck Initial Comment: subprocess.py (Python 2.5, current SVN, probably all versions) contains this O(N**2) code: bytes_written = os.write(self.stdin.fileno(), input[:512]) input = input[bytes_written:] For large but reasonable "input" the second line is rate limiting. Luckily, it is very easy to remove this bottleneck. I'll upload a simple patch. Below is a small script that demonstrates the huge speed difference. The output on my machine is: creating input 0.888417959213 slow slicing input 61.1553330421 creating input 0.863168954849 fast slicing input 0.0163860321045 done The numbers are times in seconds. This is the source: import time import sys size = 1000000 t0 = time.time() print "creating input" input = "\n".join([str(i) for i in xrange(size)]) print time.time()-t0 t0 = time.time() print "slow slicing input" n_out_slow = 0 while True: out = input[:512] n_out_slow += 1 input = input[512:] if not input: break print time.time()-t0 t0 = time.time() print "creating input" input = "\n".join([str(i) for i in xrange(size)]) print time.time()-t0 t0 = time.time() print "fast slicing input" n_out_fast = 0 input_done = 0 while True: out = input[input_done:input_done+512] n_out_fast += 1 input_done += 512 if input_done >= len(input): break print time.time()-t0 assert n_out_fast == n_out_slow print "done" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598181&group_id=5470 From noreply at sourceforge.net Fri Nov 17 07:43:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 22:43:55 -0800 Subject: [ python-Bugs-1598181 ] subprocess.py: O(N**2) bottleneck Message-ID: Bugs item #1598181, was opened at 2006-11-16 22:40 Message generated for change (Comment added) made by rwgk You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598181&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Ralf W. Grosse-Kunstleve (rwgk) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.py: O(N**2) bottleneck Initial Comment: subprocess.py (Python 2.5, current SVN, probably all versions) contains this O(N**2) code: bytes_written = os.write(self.stdin.fileno(), input[:512]) input = input[bytes_written:] For large but reasonable "input" the second line is rate limiting. Luckily, it is very easy to remove this bottleneck. I'll upload a simple patch. Below is a small script that demonstrates the huge speed difference. The output on my machine is: creating input 0.888417959213 slow slicing input 61.1553330421 creating input 0.863168954849 fast slicing input 0.0163860321045 done The numbers are times in seconds. This is the source: import time import sys size = 1000000 t0 = time.time() print "creating input" input = "\n".join([str(i) for i in xrange(size)]) print time.time()-t0 t0 = time.time() print "slow slicing input" n_out_slow = 0 while True: out = input[:512] n_out_slow += 1 input = input[512:] if not input: break print time.time()-t0 t0 = time.time() print "creating input" input = "\n".join([str(i) for i in xrange(size)]) print time.time()-t0 t0 = time.time() print "fast slicing input" n_out_fast = 0 input_done = 0 while True: out = input[input_done:input_done+512] n_out_fast += 1 input_done += 512 if input_done >= len(input): break print time.time()-t0 assert n_out_fast == n_out_slow print "done" ---------------------------------------------------------------------- >Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2006-11-16 22:43 Message: Logged In: YES user_id=71407 Originator: YES Sorry, I didn't know the tracker would destroy the indentation. I'm uploading the demo source as a separate file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598181&group_id=5470 From noreply at sourceforge.net Fri Nov 17 10:12:24 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Nov 2006 01:12:24 -0800 Subject: [ python-Bugs-1597570 ] "Report website bug" -> Forbidden :( Message-ID: Bugs item #1597570, was opened at 2006-11-16 10:19 Message generated for change (Comment added) made by pylucid You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597570&group_id=5470 Please note that this 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: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Jens Diemer (pylucid) Assigned to: Nobody/Anonymous (nobody) Summary: "Report website bug" -> Forbidden :( Initial Comment: I would report a enhancement for the python.org site. But if i go to http://pydotorg.python.org/pydotorg/newticket i see only: """ Forbidden TICKET_CREATE privileges are required to perform this operation """ :( ---------------------------------------------------------------------- >Comment By: Jens Diemer (pylucid) Date: 2006-11-17 10:12 Message: Logged In: YES user_id=1330780 Originator: YES Hm. Now i see: """ Note: self-registering on Trac is temporarily disabled. Please email sdeibel at wingware dot com to request registration. """ Anyhow, the "Forbidden error page" is not Userfiendly :( ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-16 16:07 Message: Logged In: YES user_id=849994 Originator: NO The pydotorg requires registration, which is boldly pointed out on the wiki page that the "report website bug" link refers to. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597570&group_id=5470 From noreply at sourceforge.net Fri Nov 17 10:22:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Nov 2006 01:22:07 -0800 Subject: [ python-Bugs-1597570 ] "Report website bug" -> Forbidden :( Message-ID: Bugs item #1597570, was opened at 2006-11-16 09:19 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597570&group_id=5470 Please note that this 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: Not a Bug Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Jens Diemer (pylucid) Assigned to: Nobody/Anonymous (nobody) Summary: "Report website bug" -> Forbidden :( Initial Comment: I would report a enhancement for the python.org site. But if i go to http://pydotorg.python.org/pydotorg/newticket i see only: """ Forbidden TICKET_CREATE privileges are required to perform this operation """ :( ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-17 09:22 Message: Logged In: YES user_id=849994 Originator: NO I think you're not a user but a programmer. As such, you are at least expected to read things through before clicking links ;) ---------------------------------------------------------------------- Comment By: Jens Diemer (pylucid) Date: 2006-11-17 09:12 Message: Logged In: YES user_id=1330780 Originator: YES Hm. Now i see: """ Note: self-registering on Trac is temporarily disabled. Please email sdeibel at wingware dot com to request registration. """ Anyhow, the "Forbidden error page" is not Userfiendly :( ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-16 15:07 Message: Logged In: YES user_id=849994 Originator: NO The pydotorg requires registration, which is boldly pointed out on the wiki page that the "report website bug" link refers to. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597570&group_id=5470 From noreply at sourceforge.net Fri Nov 17 11:50:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Nov 2006 02:50:10 -0800 Subject: [ python-Bugs-1597014 ] Can't exclude words before capture group Message-ID: Bugs item #1597014, was opened at 2006-11-15 14:27 Message generated for change (Comment added) made by ctimmerman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597014&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Cees Timmerman (ctimmerman) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Can't exclude words before capture group Initial Comment: Python 2.4.3 (#2, Oct 6 2006, 07:52:30) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Tried: >>> re.findall(r'(?!def)\b(\S+)\(', "def bla(): dof blu()") >>> re.findall(r'(?:def){0}\b(\S+)\(', "def bla(): dof blu()") Result: ['bla', 'blu'] Expected: ['blu'] Why doesn't (?!) work like it does here?: >>> re.findall(r'\b(\S+): (?!bad)', "bob: bad; suzy: good") ['suzy'] Wouldn't it be nice if (^) worked? >>> re.findall(r'\b(\S+): (^bad)', "bob: bad; suzy: good") [] [^()] does, sorta. Also not before a capture group: >>> re.findall(r'\b(\S+): [^(bad)]', "bob: bad; suzy: good") ['suzy'] >>> re.findall(r'[^(def)]\b(\S+)\(', "def bla(): dof blu()") ['bla', 'blu'] >>> re.findall(r'[^(def)] (\S+)\(', "def bla(): dof blu()") [] >>> re.findall(r'(^def) (\S+)\(', "def bla(): dof blu()") [('def', 'bla')] ---------------------------------------------------------------------- >Comment By: Cees Timmerman (ctimmerman) Date: 2006-11-17 10:50 Message: Logged In: YES user_id=1646092 Originator: YES I tried (^ because [^ works. (^ doesn't seem to do anything. To match ^ inside () you need to use (\^), anyway. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-15 17:20 Message: Logged In: YES user_id=849994 Originator: NO What you want is >>> re.findall(r'(? Bugs item #1597014, was opened at 2006-11-15 14:27 Message generated for change (Comment added) made by ctimmerman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1597014&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.4 Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Cees Timmerman (ctimmerman) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Can't exclude words before capture group Initial Comment: Python 2.4.3 (#2, Oct 6 2006, 07:52:30) [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2 Tried: >>> re.findall(r'(?!def)\b(\S+)\(', "def bla(): dof blu()") >>> re.findall(r'(?:def){0}\b(\S+)\(', "def bla(): dof blu()") Result: ['bla', 'blu'] Expected: ['blu'] Why doesn't (?!) work like it does here?: >>> re.findall(r'\b(\S+): (?!bad)', "bob: bad; suzy: good") ['suzy'] Wouldn't it be nice if (^) worked? >>> re.findall(r'\b(\S+): (^bad)', "bob: bad; suzy: good") [] [^()] does, sorta. Also not before a capture group: >>> re.findall(r'\b(\S+): [^(bad)]', "bob: bad; suzy: good") ['suzy'] >>> re.findall(r'[^(def)]\b(\S+)\(', "def bla(): dof blu()") ['bla', 'blu'] >>> re.findall(r'[^(def)] (\S+)\(', "def bla(): dof blu()") [] >>> re.findall(r'(^def) (\S+)\(', "def bla(): dof blu()") [('def', 'bla')] ---------------------------------------------------------------------- >Comment By: Cees Timmerman (ctimmerman) Date: 2006-11-17 11:35 Message: Logged In: YES user_id=1646092 Originator: YES Btw, thanks for the explanation, and I think you meant (?<[!=] My final pattern: >>> re.findall(r'(?>> re.findall(r'(? Bugs item #1598357, was opened at 2006-11-17 08:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598357&group_id=5470 Please note that this 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 Private: No Submitted By: thorvinrhuebarb (thorvinrhuebarb) Assigned to: Nobody/Anonymous (nobody) Summary: import curses fails Initial Comment: I am new to python and teaching myself. I downloaded and installed python 2.5 for windows from the main page, accepting all defaults. python is installed in c:\Python25 I am able to import everything else I have tried sucessfully. "sys", "os", self written code. There is a "curses" subfolder in the c:\Python25\Lib folder it contains .py versions of all of the following files __init__ ascii has_key panel textpad wrapper The documentation includes curses in the "Generic Operating System Services" >From what I have read this should indicate that can uses curses in windows (even though this was not the case in previous versions of python). When I attempt to "import curses" I get the following result. >>> import curses Traceback (most recent call last): File "", line 1, in import curses File "C:\Python25\Lib\curses\__init__.py", line 15, in from _curses import * ImportError: No module named _curses I am unsure if this is an error in documentation and curses does not in fact work with windows or if there is an error in the default windows installation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598357&group_id=5470 From noreply at sourceforge.net Fri Nov 17 14:45:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Nov 2006 05:45:03 -0800 Subject: [ python-Bugs-1598357 ] import curses fails Message-ID: Bugs item #1598357, was opened at 2006-11-17 08:40 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598357&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: thorvinrhuebarb (thorvinrhuebarb) >Assigned to: A.M. Kuchling (akuchling) Summary: import curses fails Initial Comment: I am new to python and teaching myself. I downloaded and installed python 2.5 for windows from the main page, accepting all defaults. python is installed in c:\Python25 I am able to import everything else I have tried sucessfully. "sys", "os", self written code. There is a "curses" subfolder in the c:\Python25\Lib folder it contains .py versions of all of the following files __init__ ascii has_key panel textpad wrapper The documentation includes curses in the "Generic Operating System Services" >From what I have read this should indicate that can uses curses in windows (even though this was not the case in previous versions of python). When I attempt to "import curses" I get the following result. >>> import curses Traceback (most recent call last): File "", line 1, in import curses File "C:\Python25\Lib\curses\__init__.py", line 15, in from _curses import * ImportError: No module named _curses I am unsure if this is an error in documentation and curses does not in fact work with windows or if there is an error in the default windows installation. ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-11-17 08:45 Message: Logged In: YES user_id=11375 Originator: NO The C curses library is not available for Windows. (Ports are available, but I've never seen anyone build Python with them and make the resulting binary available.) The 'curses' directory is present, but using it relies on an underlying C extension for Python called '_curses'; it's _curses that can't be built for Windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598357&group_id=5470 From noreply at sourceforge.net Fri Nov 17 14:45:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Nov 2006 05:45:29 -0800 Subject: [ python-Bugs-1598181 ] subprocess.py: O(N**2) bottleneck Message-ID: Bugs item #1598181, was opened at 2006-11-17 01:40 Message generated for change (Settings changed) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598181&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Ralf W. Grosse-Kunstleve (rwgk) >Assigned to: Peter ?strand (astrand) Summary: subprocess.py: O(N**2) bottleneck Initial Comment: subprocess.py (Python 2.5, current SVN, probably all versions) contains this O(N**2) code: bytes_written = os.write(self.stdin.fileno(), input[:512]) input = input[bytes_written:] For large but reasonable "input" the second line is rate limiting. Luckily, it is very easy to remove this bottleneck. I'll upload a simple patch. Below is a small script that demonstrates the huge speed difference. The output on my machine is: creating input 0.888417959213 slow slicing input 61.1553330421 creating input 0.863168954849 fast slicing input 0.0163860321045 done The numbers are times in seconds. This is the source: import time import sys size = 1000000 t0 = time.time() print "creating input" input = "\n".join([str(i) for i in xrange(size)]) print time.time()-t0 t0 = time.time() print "slow slicing input" n_out_slow = 0 while True: out = input[:512] n_out_slow += 1 input = input[512:] if not input: break print time.time()-t0 t0 = time.time() print "creating input" input = "\n".join([str(i) for i in xrange(size)]) print time.time()-t0 t0 = time.time() print "fast slicing input" n_out_fast = 0 input_done = 0 while True: out = input[input_done:input_done+512] n_out_fast += 1 input_done += 512 if input_done >= len(input): break print time.time()-t0 assert n_out_fast == n_out_slow print "done" ---------------------------------------------------------------------- Comment By: Ralf W. Grosse-Kunstleve (rwgk) Date: 2006-11-17 01:43 Message: Logged In: YES user_id=71407 Originator: YES Sorry, I didn't know the tracker would destroy the indentation. I'm uploading the demo source as a separate file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598181&group_id=5470 From noreply at sourceforge.net Fri Nov 17 14:48:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Nov 2006 05:48:22 -0800 Subject: [ python-Bugs-1598361 ] Misspelled submodule names for email module. Message-ID: Bugs item #1598361, was opened at 2006-11-17 15:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598361&group_id=5470 Please note that this 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 Private: No Submitted By: Dmytro O. Redchuk (truefox) Assigned to: Nobody/Anonymous (nobody) Summary: Misspelled submodule names for email module. Initial Comment: There are at http://docs.python.org/lib/module-email.html and below some errors in submodule names: ---------- # taken from # http://docs.python.org/lib/module-email.message.html : >>> from email.generator import Generator ---------- Traceback (most recent call last): File "", line 1, in ? ImportError: No module named generator >>> from email.Generator import Generator >>> The same for email.Message, email.Header and, probably, others (they start with lowercase letters). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598361&group_id=5470 From noreply at sourceforge.net Fri Nov 17 14:56:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Nov 2006 05:56:20 -0800 Subject: [ python-Bugs-1583946 ] SSL "issuer" and "server" names cannot be parsed Message-ID: Bugs item #1583946, was opened at 2006-10-24 14:32 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: John Nagle (nagle) Assigned to: Nobody/Anonymous (nobody) Summary: SSL "issuer" and "server" names cannot be parsed Initial Comment: (Python 2.5 library) The Python SSL object offers two methods from obtaining the info from an SSL certificate, "server()" and "issuer()". These return strings. The actual values in the certificate are a series of key /value pairs in ASN.1 binary format. But what "server()" and "issuer()" return are single strings, with the key/value pairs separated by "/". However, "/" is a valid character in certificate data. So parsing such strings is ambiguous, and potentially exploitable. This is more than a theoretical problem. The issuer field of Verisign certificates has a "/" in the middle of a text field: "/O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign". Note the "OU=Terms of use at www.verisign.com/rpa (c)00" with a "/" in the middle of the value field. Oops. Worse, this is potentially exploitable. By ordering a low-level certificate with a "/" in the right place, you can create the illusion (at least for flawed implementations like this one) that the certificate belongs to someone else. Just order a certificate from GoDaddy, enter something like this in the "Name" field "Myphonyname/C=US/ST=California/L=San Jose/O=eBay Inc./OU=Site Operations/CN=signin.ebay.com" and Python code will be spoofed into thinking you're eBay. Fortunately, browsers don't use Python code. The actual bug is in python/trunk/Modules/_ssl.c at if ((self->server_cert = SSL_get_peer_certificate(self->ssl))) { X509_NAME_oneline(X509_get_subject_name(self->server_cert), self->server, X509_NAME_MAXLEN); X509_NAME_oneline(X509_get_issuer_name(self->server_cert), self->issuer, X509_NAME_MAXLEN); The "X509_name_oneline" function takes an X509_NAME structure, which is the certificate system's representation of a list, and flattens it into a printable string. This is a debug function, not one for use in production code. The SSL documentation for "X509_name_oneline" says: "The functions X509_NAME_oneline() and X509_NAME_print() are legacy functions which produce a non standard output form, they don't handle multi character fields and have various quirks and inconsistencies. Their use is strongly discouraged in new applications." What OpenSSL callers are supposed to do is call X509_NAME_entry_count() to get the number of entries in an X509_NAME structure, then get each entry with X509_NAME_get_entry(). A few more calls will obtain the name/value pair from the entry, as UTF8 strings, which should be converted to Python UNICODE strings. OpenSSL has all the proper support, but Python's shim doesn't interface to it correctly. X509_NAME_oneline() doesn't handle Unicode; it converts non-ASCII values to "\xnn" format. Again, it's for debug output only. So what's needed are two new functions for Python's SSL sockets to replace "issuer" and "server". The new functions should return lists of Unicode strings representing the key/value pairs. (A list is needed, not a dictionary; two strings with the same key are both possible and common.) The reason this now matters is that new "high assurance" certs, the ones that tell you how much a site can be trusted, are now being deployed, and to use them effectively, you need that info. Support for them is in Internet Explorer 7, so they're going to be widespread soon. Python needs to catch up. And, of course, this needs to be fixed as part of Unicode support. John Nagle Animats ---------------------------------------------------------------------- >Comment By: A.M. Kuchling (akuchling) Date: 2006-11-17 08:56 Message: Logged In: YES user_id=11375 Originator: NO The request is bug #1425 in the OpenSSL request tracker (go to openssl.org > Support for a link). ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2006-11-08 02:02 Message: Logged In: YES user_id=5571 I've submitted a request (titled "Request: make X509_NAME_oneline() use same formatter as X509_NAME_print_ex()") to the OpenSSL developers to fix this on their side. If they fix that, delimiters will be escaped per the standard. The OpenSSL people should also export the functionality of getting this information as a UTF8 string, and if they do, Python should use that call as part of Unicode support. Keep this open pending action on the OpenSSL side. Thanks. ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-10-27 08:54 Message: Logged In: YES user_id=11375 I've reworded the description in the documentation to say something like this: "Returns a string describing the issuer of the server's certificate. Useful for debugging purposes; do not parse the content of this string because its format can't be parsed unambiguously." For adding new features: please submit a patch. Python's maintainers probably don't use SSL in any sophisticated way and therefore have no idea what shape better SSL/X.509 support would take. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-25 14:05 Message: Logged In: YES user_id=21627 Notice that RFC 2253 has been superceded by RFC 4514 (see my earlier message). However, I really see no reason to fix this: even if the ambiguity problems were fixed, you *still* should not use the issuer and subject names in a security-relevant context. ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2006-10-25 13:26 Message: Logged In: YES user_id=5571 Actually, they don't do what they're "designed to do". According to the Python library documentation for SSL objects, the server method "Returns a string containing the ASN.1 distinguished name identifying the server's certificate. (See below for an example showing what distinguished names look like.)" The example "below" is missing from the documentation, so the documentation gives us no clue of what to expect. There are several standardized representations for ASN.1 information. See "http://www.oss.com/asn1/tutorial/Explain.html" Most are binary. The only standard textual form is "XER", which is an XML representation of ASN.1 encoded information. It's essentially the same representation used for parameters in SOAP. So, given the documentation and the standard, what should be coming out is the XML representation of that data. Here's an entire X.509 certificate in XML: http://www.gnu.org/software/gnutls/manual/html_node/An-X_002e509-certificate.html The "issuer" field can be seen in there. It's awfully bulky. And making SSL dependent on the SOAP module probably isn't desireable. But that's an ASN.1 distinguished name in XML format, per the standard. That's probably not what's wanted by most users, although the ability to retrieve an entire certificate in XML format would be useful. However, there's another standard string encoding, which is defined in RFC2253. This is comma-separated UTF-8 with backslash escapes for special characters. That's reliably parseable. There's an openSSL function, "X509_NAME_print_ex", which does this formatting, but it doesn't output to a string. That's the right mechanism if it can be invoked in some way to yield a string. It should be invoked with flags = ASN1_STRFLGS_RFC2253, which yields a UTF8 string, which of course should become a Python Unicode string. Now if someone can figure out how to get a string, instead of file output, out of OpenSSL's "X509_NAME_print_ex", we're home. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-25 04:38 Message: Logged In: YES user_id=21627 The bug is not in the the server() and issuer() methods (which do exactly what they are meant to do); the bug is in applications which assume that the result of these methods can be parsed. As you point out, it cannot. The functions, as is, don't present a security problem. If their result is presented as-is to the user, the user can determine herself whether she recognizes the entity referred-to in the distinguished name. Notice that it is certainly possible to produce an unambigous string representation of a distinguished name; RFC 4514 specifies an algorithm to do so (for use within LDAP). Also notice that that the SSL module does little to actually support trust: there is no verification of server-side certs, no access to extensions of a certificate, etc. So an application and a user should *not* trust the issuer name it received, anyway (unless there is an independent verification that the server certificate can be trusted). All that said: If you think you need this functionality, please provide a patch to implement it. ---------------------------------------------------------------------- Comment By: John Nagle (nagle) Date: 2006-10-24 18:40 Message: Logged In: YES user_id=5571 The problem isn't in the version of OpenSSL used in Python, which is at 0.9.8a. OpenSSL has had the necessary functions for years. But Python isn't using them. It's in "python/trunk/Modules/_ssl.c", as described above. ---------------------------------------------------------------------- Comment By: Gregory P. Smith (greg) Date: 2006-10-24 18:05 Message: Logged In: YES user_id=413 Yes OpenSSL 0.9.8d or later should be used for a new binary release. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4343 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3738 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2940 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2937 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1583946&group_id=5470 From noreply at sourceforge.net Fri Nov 17 20:46:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Nov 2006 11:46:00 -0800 Subject: [ python-Bugs-1598361 ] Misspelled submodule names for email module. Message-ID: Bugs item #1598361, was opened at 2006-11-17 13:48 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598361&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Dmytro O. Redchuk (truefox) Assigned to: Nobody/Anonymous (nobody) Summary: Misspelled submodule names for email module. Initial Comment: There are at http://docs.python.org/lib/module-email.html and below some errors in submodule names: ---------- # taken from # http://docs.python.org/lib/module-email.message.html : >>> from email.generator import Generator ---------- Traceback (most recent call last): File "", line 1, in ? ImportError: No module named generator >>> from email.Generator import Generator >>> The same for email.Message, email.Header and, probably, others (they start with lowercase letters). ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-17 19:46 Message: Logged In: YES user_id=849994 Originator: NO This is not a bug, you're looking at the docs for Python 2.5, and there the email submodules are accessible by lower case names too. In the 2.4 docs there's still the old titlecased name. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598361&group_id=5470 From noreply at sourceforge.net Fri Nov 17 22:26:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Nov 2006 13:26:42 -0800 Subject: [ python-Bugs-1598620 ] ctypes Structure allows recursive definition Message-ID: Bugs item #1598620, was opened at 2006-11-17 13: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=1598620&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Lenard Lindstrom (kermode) Assigned to: Nobody/Anonymous (nobody) Summary: ctypes Structure allows recursive definition Initial Comment: Ctypes version 1.0.1 and Python 2.4: A Partially declared structure can be used as a type in its own field declarations: Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import Structure, c_int, sizeof, __version__ >>> __version__ '1.0.1' >>> class S(Structure): ... pass ... >>> S._fields_ = [('i', c_int), ('s', S)] >>> sizeof(S) 4 >>> o=S(7) >>> o.s.i=12 >>> o.s.s.i=20 >>> o.i 7 >>> o.s.i 12 >>> o.s.s.i 20 >>> sizeof(o) 4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598620&group_id=5470 From noreply at sourceforge.net Sat Nov 18 00:10:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 17 Nov 2006 15:10:26 -0800 Subject: [ python-Bugs-1598620 ] ctypes Structure allows recursive definition Message-ID: Bugs item #1598620, was opened at 2006-11-17 22:26 Message generated for change (Settings changed) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598620&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Lenard Lindstrom (kermode) >Assigned to: Thomas Heller (theller) Summary: ctypes Structure allows recursive definition Initial Comment: Ctypes version 1.0.1 and Python 2.4: A Partially declared structure can be used as a type in its own field declarations: Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import Structure, c_int, sizeof, __version__ >>> __version__ '1.0.1' >>> class S(Structure): ... pass ... >>> S._fields_ = [('i', c_int), ('s', S)] >>> sizeof(S) 4 >>> o=S(7) >>> o.s.i=12 >>> o.s.s.i=20 >>> o.i 7 >>> o.s.i 12 >>> o.s.s.i 20 >>> sizeof(o) 4 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598620&group_id=5470 From noreply at sourceforge.net Sat Nov 18 19:49:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Nov 2006 10:49:49 -0800 Subject: [ python-Bugs-1472877 ] Tix: Subwidget names Message-ID: Bugs item #1472877, was opened at 2006-04-19 12:26 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472877&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Matthias Kievernagel (mkiever) Assigned to: Martin v. L?wis (loewis) Summary: Tix: Subwidget names Initial Comment: My system information: ------------------------------------------ uname -a: Linux linux 2.6.4-52-default #1 Wed Apr 7 02:08:30 UTC 2004 i686 athlon i386 GNU/Linux Python: Python 2.4.1 (#4, Jan 10 2006, 10:53:14) [GCC 3.3.3 (SuSE Linux)] on linux2 and Python 2.3.5 (#1, Sep 12 2005, 14:56:24) [GCC 3.3.3 (SuSE Linux)] on linux2 ------------------------------------------ Using Tix you can produce the following exception: --------------------------------------------------- >>> from Tix import * >>> tk = Tk () >>> b = Balloon () >>> b.subwidget ( 'label' ) Traceback (most recent call last): File "", line 1, in ? File "/home/mkiever/pro/Python-2.4.1/Lib/lib-tk/Tix. py", line 340, in subwidget return self._nametowidget(n) File "/home/mkiever/pro/Python-2.4.1/Lib/lib-tk/ Tkinter.py", line 1015, in nametowidget w = w.children[name] KeyError: 'lab' >>> --------------------------------------------------- I found a commentary in Tix.py:TixWidget:__init__ stating that 'subwidget_list' should contain Tix names. But in Tix.py:TixSubWidget:__init__ the python names are used, not the names returned by Tix. I was successful with the following two small additions (+++) near lines 400-450: --------------------------------------------- class TixSubWidget(TixWidget): ... def __init__(self, master, name, destroy_physically=1, check_intermediate=1): ... if (not check_intermediate) or len(plist) < 2: # immediate descendant if check_intermediate: +++ name = plist [0] +++ TixWidget.__init__(self, master, None, None, {'name' : name}) else: ... name = plist [-1] +++ TixWidget.__init__(self, parent, None, None, {'name' : name}) self.destroy_physically = destroy_physically ... --------------------------------------------- This replaces the python name by the name returned from Tix. I have not extensively tested this (sorry). Hope this helps. Matthias Kievernagel (mkiever at web.de) ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-18 19:49 Message: Logged In: YES user_id=21627 Originator: NO Fixed with said patch. ---------------------------------------------------------------------- Comment By: Matthias Kievernagel (mkiever) Date: 2006-10-25 22:36 Message: Logged In: YES user_id=1477880 Solution was not complete. Submitted a complete patch #1472877 for this which is tested against the tix demo code in Demo/tix/tixwidgets.py Matthias Kievernagel mkiever at web dot de ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472877&group_id=5470 From noreply at sourceforge.net Sat Nov 18 20:22:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Nov 2006 11:22:05 -0800 Subject: [ python-Bugs-1591319 ] replace groups doesn't work in this special case Message-ID: Bugs item #1591319, was opened at 2006-11-06 11:49 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591319&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Regular Expressions Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Thomas K. (tomek74) Assigned to: Gustavo Niemeyer (niemeyer) Summary: replace groups doesn't work in this special case Initial Comment: If you have a regular expression like this: ([0-9])([a-z])? matching this string: 1 1a and replacing with this: yx you get what expected: yx yx BUT: If you replace with this: \1\2 you get nothing replaced, because the group \2 doesn't exist for the pattern "1". But it does exist for the pattern "1a"! We have multiple possibilities here: 1.) The string "1" gives no result, because \2 doesn't exist. The string "1a" gives a result, so the output should be: 1a 2.) The sring "1" gives a result, because \2 is handled like an empty string. The string "1a" gives a result, so the output should be: 1 1a I think the case that the sring "1" has no results, but effects the string "1a" wich would normaly have a result, is bad. What are your thoughts on it? Test code: import re # common variables rawstr = r"""([0-9])([a-z])?""" embedded_rawstr = r"""([0-9])([a-z])?""" matchstr = """1 1a""" # method 1: using a compile object compile_obj = re.compile(rawstr) match_obj = compile_obj.search(matchstr) # method 2: using search function (w/ external flags) match_obj = re.search(rawstr, matchstr) # method 3: using search function (w/ embedded flags) match_obj = re.search(embedded_rawstr, matchstr) # Retrieve group(s) from match_obj all_groups = match_obj.groups() # Retrieve group(s) by index group_1 = match_obj.group(1) group_2 = match_obj.group(2) # Replace string newstr = compile_obj.subn('\1\2', 0) ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-18 19:22 Message: Logged In: YES user_id=849994 Originator: NO I do get a match with your regex and search string 2. ---------------------------------------------------------------------- Comment By: Thomas K. (tomek74) Date: 2006-11-08 16:56 Message: Logged In: YES user_id=22427 I have tried it again with my original regexp and the searchstring. In this case I have to put the ??? after ?)?. -> RegEx: ([1-9][a-z][a-z][0-9])([ \-\r\n\t]*([0-9])(([0-9])(([0-9])([ \-\r\n\t]*([0-9])(([a-z])(([a-z])(([0-9])(([0-9])([ \-\r\n\t]*([0-9])(([a-z])(([a-z])(([0-9]))?)?)?)?)?)?)?)?)?)?)?)? IGNORECASE is switched on. -> ReplaceString: \1\3\5\7\9\11\13\15\17\19\21\23\25 -> Searchstring 1): 6ES5894-0MA63-0UG5 Result: 6ES58940MA630UG5 -> Searchstring 2): 6ES5894-0MA03; 6ES5864-0MA03; 6ES5894-0MA63-0UG5; 6ES58860MA03 Result: NO Result! -> The problem is that I get no results with searchstring 2. Thomas ---------------------------------------------------------------------- Comment By: Thomas K. (tomek74) Date: 2006-11-07 10:36 Message: Logged In: YES user_id=22427 I verified your code. It works for me, too. Sorry. ---------------------------------------------------------------------- Comment By: Gustavo Niemeyer (niemeyer) Date: 2006-11-06 12:17 Message: Logged In: YES user_id=7887 Hello Thomas, I don't understand exactly what you mean here. This doesn't work: >>> re.compile("([0-9])([a-z])?").subn(r"<\1\2>", "1 1a") Traceback (most recent call last): ... sre_constants.error: unmatched group And this works fine: >>> re.compile("([0-9])([a-z]?)").subn(r"<\1\2>", "1 1a") ('<1> <1a>', 2) The example code you provided doesn't run here, because 'subn()' is being provided bad data (check http://docs.python.org/lib/node46.html for docs). It's also being passed '\1\2', which is really '\x01\x02', and won't do what you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1591319&group_id=5470 From noreply at sourceforge.net Sun Nov 19 02:47:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Nov 2006 17:47:13 -0800 Subject: [ python-Bugs-1599055 ] csv library does not handle '\x00' Message-ID: Bugs item #1599055, was opened at 2006-11-18 20: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=1599055&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Stephen Day (shday) Assigned to: Nobody/Anonymous (nobody) Summary: csv library does not handle '\x00' Initial Comment: The following from an interactive session failed instead of just returning the '\x00': >>> r = csv.reader(['a,line,with,a,null,\x00,byte']) >>> r.next() Traceback (most recent call last): File "", line 1, in -toplevel- r.next() Error: string with NUL bytes >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&group_id=5470 From noreply at sourceforge.net Sun Nov 19 02:54:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 18 Nov 2006 17:54:09 -0800 Subject: [ python-Bugs-1599055 ] csv module does not handle '\x00' Message-ID: Bugs item #1599055, was opened at 2006-11-18 20:47 Message generated for change (Settings changed) made by shday You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Stephen Day (shday) Assigned to: Nobody/Anonymous (nobody) >Summary: csv module does not handle '\x00' Initial Comment: The following from an interactive session failed instead of just returning the '\x00': >>> r = csv.reader(['a,line,with,a,null,\x00,byte']) >>> r.next() Traceback (most recent call last): File "", line 1, in -toplevel- r.next() Error: string with NUL bytes >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&group_id=5470 From noreply at sourceforge.net Sun Nov 19 09:15:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 00:15:06 -0800 Subject: [ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not work Message-ID: Bugs item #1579029, was opened at 2006-10-17 17:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Martin v. L?wis (loewis) Summary: --disable-sunaudiodev --disable-tk does not work Initial Comment: trying to disable sunaudiodev and tk does not really work in solaris. ./configure --prefix=/usr/local/Python-2.5 --enable- shared --disable-sunaudiodev --disable-tk building 'sunaudiodev' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/sunaudiodev.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/sunaudiodev.o /usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: sun/audioio.h: No such file or directory building '_tkinter' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -DWITH_APPINIT=1 - I/usr/openwin/include -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/_tkinter.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/_tkinter.o In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:96:23: X11/Xlib.h: No such file or directory In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:572: error: syntax error before "Window" /usr/local/include/tk.h:572: error: `Window' declared as function returning a function /usr/local/include/tk.h:575: error: syntax error before "XEvent" /usr/local/include/tk.h:584: error: syntax error before "Tk_ClassCreateProc" /usr/local/include/tk.h:592: error: syntax error before '}' token /usr/local/include/tk.h:678: error: syntax error before "Bool" is it possible to correct this or state clearly in the configure options how to disable it correctly? we also checked the Modules/Setup and both seems commented. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 09:15 Message: Logged In: YES user_id=21627 Originator: NO Closing as "won't fix". There are no plans to implement --disable-sunaudiodev --disable-tk options to configure. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-06 18:51 Message: Logged In: YES user_id=21627 The component isn't vital. It shouldn't be relevant for building sunaudiodev whether an audio device is present in the system, as this device isn't necessary for *building* Python. Instead, presence of /usr/include/sys/audioio.h is necessary. I'm puzzled that this file isn't there (it is part of the core development environment, AFAIK); the build process assumes that the header is present if the system name is "sunos5". ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-06 10:23 Message: Logged In: YES user_id=1597584 i would appreciate if the build completes without errors. i won't care if it attemts to build, but it should figure out that the sunaudiodev is not there. to my knowledge servers do not need that component. and python should not need it too then. do you see any reason why these components are vital for python? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-04 00:25 Message: Logged In: YES user_id=21627 It doesn't build the modules, as it doesn't succeed when attempting to. Why do you want it not to attempt? ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-03 12:56 Message: Logged In: YES user_id=1597584 what do you suggest then to convince the build not to build it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-02 06:40 Message: Logged In: YES user_id=21627 Re: enable/disable: What makes you think "sunaudiodev" and "tk" are valid values for "FEATURE"? configure --help lists the valid values for FEATURE, namely universalsdk, framework, shared, profiling, toolbox-glue, ipv6, and unicode. Re: there is a compilation error. Sure, an error is reported. However, compilation should not fail because of that. Instead, compilation should complete successfully, and just end up not building these modules. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-02 00:31 Message: Logged In: YES user_id=1597584 and there is no X on the server. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:49 Message: Logged In: YES user_id=1597584 and what does that mean? Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:47 Message: Logged In: YES user_id=1597584 because there is a compilation error with both. sunaudio.h seems not to exist on our server, and tk gives other compilation errors. and i have no idea why i would need these modules on our server. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-17 17:43 Message: Logged In: YES user_id=21627 I fail to see a bug here. What makes you think --disable-sunaudiodev --disable-tk exist? ./configure --help does not claim they do. In fact, it is not possible to disable modules. Why do you want that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 From noreply at sourceforge.net Sun Nov 19 11:39:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 02:39:39 -0800 Subject: [ python-Bugs-1579931 ] not configured for tk Message-ID: Bugs item #1579931, was opened at 2006-10-18 21:59 Message generated for change (Comment added) made by nironius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579931&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Carl Wenrich (carlwenrich) Assigned to: Nobody/Anonymous (nobody) Summary: not configured for tk Initial Comment: When I try to run the sample tkinter script (hello.py) I get a message saying my python isn't configured for tk. ---------------------------------------------------------------------- Comment By: Borisov Michael (nironius) Date: 2006-11-19 12:39 Message: Logged In: YES user_id=1649012 Originator: NO You must install Tk libraries for working ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-19 00:06 Message: Logged In: YES user_id=21627 Why do you think this is a bug? What operating system are you using, and where do your Python binaries come from? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579931&group_id=5470 From noreply at sourceforge.net Sun Nov 19 11:39:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 02:39:52 -0800 Subject: [ python-Bugs-1579931 ] not configured for tk Message-ID: Bugs item #1579931, was opened at 2006-10-18 21:59 Message generated for change (Comment added) made by nironius You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579931&group_id=5470 Please note that this 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.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Carl Wenrich (carlwenrich) Assigned to: Nobody/Anonymous (nobody) Summary: not configured for tk Initial Comment: When I try to run the sample tkinter script (hello.py) I get a message saying my python isn't configured for tk. ---------------------------------------------------------------------- Comment By: Borisov Michael (nironius) Date: 2006-11-19 12:39 Message: Logged In: YES user_id=1649012 Originator: NO You must install Tk libraries for working ---------------------------------------------------------------------- Comment By: Borisov Michael (nironius) Date: 2006-11-19 12:39 Message: Logged In: YES user_id=1649012 Originator: NO You must install Tk libraries for working ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-19 00:06 Message: Logged In: YES user_id=21627 Why do you think this is a bug? What operating system are you using, and where do your Python binaries come from? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579931&group_id=5470 From noreply at sourceforge.net Sun Nov 19 12:00:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 03:00:16 -0800 Subject: [ python-Bugs-1579931 ] not configured for tk Message-ID: Bugs item #1579931, was opened at 2006-10-18 20:59 Message generated for change (Settings changed) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579931&group_id=5470 Please note that this 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.4 >Status: Pending >Resolution: Invalid Priority: 5 Private: No Submitted By: Carl Wenrich (carlwenrich) Assigned to: Nobody/Anonymous (nobody) Summary: not configured for tk Initial Comment: When I try to run the sample tkinter script (hello.py) I get a message saying my python isn't configured for tk. ---------------------------------------------------------------------- Comment By: Borisov Michael (nironius) Date: 2006-11-19 11:39 Message: Logged In: YES user_id=1649012 Originator: NO You must install Tk libraries for working ---------------------------------------------------------------------- Comment By: Borisov Michael (nironius) Date: 2006-11-19 11:39 Message: Logged In: YES user_id=1649012 Originator: NO You must install Tk libraries for working ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-18 23:06 Message: Logged In: YES user_id=21627 Why do you think this is a bug? What operating system are you using, and where do your Python binaries come from? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579931&group_id=5470 From noreply at sourceforge.net Sun Nov 19 16:09:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 07:09:20 -0800 Subject: [ python-Bugs-1599055 ] csv module does not handle '\x00' Message-ID: Bugs item #1599055, was opened at 2006-11-19 01:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Stephen Day (shday) Assigned to: Nobody/Anonymous (nobody) Summary: csv module does not handle '\x00' Initial Comment: The following from an interactive session failed instead of just returning the '\x00': >>> r = csv.reader(['a,line,with,a,null,\x00,byte']) >>> r.next() Traceback (most recent call last): File "", line 1, in -toplevel- r.next() Error: string with NUL bytes >>> ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-19 15:09 Message: Logged In: YES user_id=849994 Originator: NO Why do you think a CSV reader should support null bytes? CSV is a text format, not a binary one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&group_id=5470 From noreply at sourceforge.net Sun Nov 19 17:03:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 08:03:08 -0800 Subject: [ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace Message-ID: Bugs item #1599254, was opened at 2006-11-19 16:03 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: David Watson (baikie) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 From noreply at sourceforge.net Sun Nov 19 17:08:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 08:08:52 -0800 Subject: [ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace Message-ID: Bugs item #1599254, was opened at 2006-11-19 16:03 Message generated for change (Settings changed) made by baikie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 Please note that this message will contain 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: 7 Private: No Submitted By: David Watson (baikie) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 From noreply at sourceforge.net Sun Nov 19 18:08:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 09:08:57 -0800 Subject: [ python-Bugs-1599055 ] csv module does not handle '\x00' Message-ID: Bugs item #1599055, was opened at 2006-11-18 20:47 Message generated for change (Comment added) made by shday You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Stephen Day (shday) Assigned to: Nobody/Anonymous (nobody) Summary: csv module does not handle '\x00' Initial Comment: The following from an interactive session failed instead of just returning the '\x00': >>> r = csv.reader(['a,line,with,a,null,\x00,byte']) >>> r.next() Traceback (most recent call last): File "", line 1, in -toplevel- r.next() Error: string with NUL bytes >>> ---------------------------------------------------------------------- >Comment By: Stephen Day (shday) Date: 2006-11-19 12:08 Message: Logged In: YES user_id=948502 Originator: YES I've been using the csv module to parse data coming from a serial port of a lab instrument. Occasionally the instrument transmits a lone /x00 (maybe when the power cycles, I'm not sure). Anyhow, I'm now using a try-except statement to catch the error. I guess my answer to your question is that I think the module should handle whatever string you pass it. Is there a specific reason not to handle /x00? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-19 10:09 Message: Logged In: YES user_id=849994 Originator: NO Why do you think a CSV reader should support null bytes? CSV is a text format, not a binary one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&group_id=5470 From noreply at sourceforge.net Sun Nov 19 18:23:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 09:23:10 -0800 Subject: [ python-Bugs-1599055 ] csv module does not handle '\x00' Message-ID: Bugs item #1599055, was opened at 2006-11-19 01:47 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Stephen Day (shday) Assigned to: Nobody/Anonymous (nobody) Summary: csv module does not handle '\x00' Initial Comment: The following from an interactive session failed instead of just returning the '\x00': >>> r = csv.reader(['a,line,with,a,null,\x00,byte']) >>> r.next() Traceback (most recent call last): File "", line 1, in -toplevel- r.next() Error: string with NUL bytes >>> ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-19 17:23 Message: Logged In: YES user_id=849994 Originator: NO The core of the csv module is coded in C, so null bytes are as always notoriously problematic when handling strings. (This is why there's a specific error message only for null bytes.) I think that the try-except is the sanest solution to this. ---------------------------------------------------------------------- Comment By: Stephen Day (shday) Date: 2006-11-19 17:08 Message: Logged In: YES user_id=948502 Originator: YES I've been using the csv module to parse data coming from a serial port of a lab instrument. Occasionally the instrument transmits a lone /x00 (maybe when the power cycles, I'm not sure). Anyhow, I'm now using a try-except statement to catch the error. I guess my answer to your question is that I think the module should handle whatever string you pass it. Is there a specific reason not to handle /x00? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-19 15:09 Message: Logged In: YES user_id=849994 Originator: NO Why do you think a CSV reader should support null bytes? CSV is a text format, not a binary one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&group_id=5470 From noreply at sourceforge.net Sun Nov 19 20:40:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 11:40:19 -0800 Subject: [ python-Bugs-1599325 ] htmlentitydefs.entitydefs assumes Latin-1 encoding Message-ID: Bugs item #1599325, was opened at 2006-11-19 14:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599325&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Erik Demaine (edemaine) Assigned to: Nobody/Anonymous (nobody) Summary: htmlentitydefs.entitydefs assumes Latin-1 encoding Initial Comment: The code in htmlentitydefs.py that sets entitydefs uses chr whenever the codepoint is <= 0xff. This should be <= 0x7f. As it currently stands, htmlentitydefs.entitydefs['nbsp'] == '\xa0'. But this is only "true" in the Latin-1 encoding. For example, in UTF8, the same character (u'\xa0') would be encoded '\xc2\xa0'. While I think it is reasonable for entitydefs to use the ASCII codec for characters encodable in that codec (<= 0x7f), I do not think it is reasonable to assume Latin-1 encoding. This issue affects sgmllib.SGMLParser, for example, when handle_entityref calls handle_data. The passed data can be '\xa0', which handle_data is forced to assume is Latin-1, when the source string might be encoded otherwise. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599325&group_id=5470 From noreply at sourceforge.net Sun Nov 19 20:47:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 11:47:30 -0800 Subject: [ python-Feature Requests-1599329 ] urllib(2) should allow automatic decoding by charset Message-ID: Feature Requests item #1599329, was opened at 2006-11-19 14:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1599329&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Erik Demaine (edemaine) Assigned to: Nobody/Anonymous (nobody) Summary: urllib(2) should allow automatic decoding by charset Initial Comment: Currently, urllib.urlopen(...).read() returns a string, not a unicode object. Ditto for urllib2. No attempt is made to decode the data using the charset encoding specified in the header ....info()['Content-Type']. Is it fair to assume that, in Python 3K, urllib....read() will return (Unicode) strings instead of bytes, automatically decoding according to the charset? Do you think we could expose this futuristic functionality in Python 2? I doubt we could change read() without breaking a lot of existing code that already does this decoding (e.g., http://zesty.ca/python/scrape.py), but perhaps a 'uread()' method could return a unicode object instead of a string. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1599329&group_id=5470 From noreply at sourceforge.net Sun Nov 19 20:59:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 11:59:00 -0800 Subject: [ python-Bugs-1599325 ] htmlentitydefs.entitydefs assumes Latin-1 encoding Message-ID: Bugs item #1599325, was opened at 2006-11-19 20:40 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599325&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Erik Demaine (edemaine) Assigned to: Nobody/Anonymous (nobody) Summary: htmlentitydefs.entitydefs assumes Latin-1 encoding Initial Comment: The code in htmlentitydefs.py that sets entitydefs uses chr whenever the codepoint is <= 0xff. This should be <= 0x7f. As it currently stands, htmlentitydefs.entitydefs['nbsp'] == '\xa0'. But this is only "true" in the Latin-1 encoding. For example, in UTF8, the same character (u'\xa0') would be encoded '\xc2\xa0'. While I think it is reasonable for entitydefs to use the ASCII codec for characters encodable in that codec (<= 0x7f), I do not think it is reasonable to assume Latin-1 encoding. This issue affects sgmllib.SGMLParser, for example, when handle_entityref calls handle_data. The passed data can be '\xa0', which handle_data is forced to assume is Latin-1, when the source string might be encoded otherwise. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 20:59 Message: Logged In: YES user_id=21627 Originator: NO This is not a bug. entitydefs is specified to contain Latin-1 byte strings in its documentation, and many applications rely on that. If you have different processing needs, you may want to use htmlentitydefs.name2codepoint instead, or derive yet another table automatically from it. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599325&group_id=5470 From noreply at sourceforge.net Sun Nov 19 21:02:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 12:02:16 -0800 Subject: [ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace Message-ID: Bugs item #1599254, was opened at 2006-11-19 17:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: David Watson (baikie) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 21:02 Message: Logged In: YES user_id=21627 Originator: NO Mailbox locking was invented precisely to support this kind of operation. Why do you complain that things break if you deliberately turn off the mechanism preventing breakage? I fail to see a bug here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 From noreply at sourceforge.net Sun Nov 19 21:17:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 12:17:41 -0800 Subject: [ python-Bugs-1599055 ] csv module does not handle '\x00' Message-ID: Bugs item #1599055, was opened at 2006-11-18 19:47 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Stephen Day (shday) Assigned to: Nobody/Anonymous (nobody) Summary: csv module does not handle '\x00' Initial Comment: The following from an interactive session failed instead of just returning the '\x00': >>> r = csv.reader(['a,line,with,a,null,\x00,byte']) >>> r.next() Traceback (most recent call last): File "", line 1, in -toplevel- r.next() Error: string with NUL bytes >>> ---------------------------------------------------------------------- >Comment By: Skip Montanaro (montanaro) Date: 2006-11-19 14:17 Message: Logged In: YES user_id=44345 Originator: NO If the device is transmitting the occasional spurious you might try wrapping your file object in a class which simply deletes any NUL bytes it encounters. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-19 11:23 Message: Logged In: YES user_id=849994 Originator: NO The core of the csv module is coded in C, so null bytes are as always notoriously problematic when handling strings. (This is why there's a specific error message only for null bytes.) I think that the try-except is the sanest solution to this. ---------------------------------------------------------------------- Comment By: Stephen Day (shday) Date: 2006-11-19 11:08 Message: Logged In: YES user_id=948502 Originator: YES I've been using the csv module to parse data coming from a serial port of a lab instrument. Occasionally the instrument transmits a lone /x00 (maybe when the power cycles, I'm not sure). Anyhow, I'm now using a try-except statement to catch the error. I guess my answer to your question is that I think the module should handle whatever string you pass it. Is there a specific reason not to handle /x00? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-19 09:09 Message: Logged In: YES user_id=849994 Originator: NO Why do you think a CSV reader should support null bytes? CSV is a text format, not a binary one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&group_id=5470 From noreply at sourceforge.net Sun Nov 19 21:44:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 12:44:25 -0800 Subject: [ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace Message-ID: Bugs item #1599254, was opened at 2006-11-19 16:03 Message generated for change (Comment added) made by baikie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: David Watson (baikie) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. ---------------------------------------------------------------------- >Comment By: David Watson (baikie) Date: 2006-11-19 20:44 Message: Logged In: YES user_id=1504904 Originator: YES This is a bug. The point is that the code is subverting the protection of its own fcntl locking. I should have pointed out that Postfix was still using fcntl locking, and that should have been sufficient. (In fact, it was due to its use of fcntl locking that it chose precisely the wrong moment to deliver mail.) Dot-locking does protect against this, but not every program uses it - which is precisely the reason that the code implements fcntl locking in the first place. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 20:02 Message: Logged In: YES user_id=21627 Originator: NO Mailbox locking was invented precisely to support this kind of operation. Why do you complain that things break if you deliberately turn off the mechanism preventing breakage? I fail to see a bug here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 From noreply at sourceforge.net Mon Nov 20 04:20:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 19 Nov 2006 19:20:05 -0800 Subject: [ python-Bugs-1590592 ] where is zlib??? Message-ID: <200611200320.kAK3K5CS025489@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1590592, was opened at 2006-11-04 11:51 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590592&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: AKap (aleksey_kap) Assigned to: Nobody/Anonymous (nobody) Summary: where is zlib??? Initial Comment: Python2.5 for win32 msi-installer - where are zlib.dll and zlib.pyd ??? ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2006-11-19 19:20 Message: Logged In: YES user_id=1312539 Originator: NO 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: Martin v. L?wis (loewis) Date: 2006-11-05 15:12 Message: Logged In: YES user_id=21627 They aren't part of the distribution. Why do you think they should be? zlib is linked into python25.dll. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1590592&group_id=5470 From noreply at sourceforge.net Mon Nov 20 12:33:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 03:33:50 -0800 Subject: [ python-Bugs-978833 ] SSL-ed sockets don't close correct? Message-ID: Bugs item #978833, was opened at 2004-06-24 09:57 Message generated for change (Settings changed) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: SSL-ed sockets don't close correct? Initial Comment: When testing FTP over SSL I have strong doubt, that ssl-ed sockets are not closed correctly. (This doesn't show with https because nobody takes care about whats going on "after the party".) See the following : --- I need to run FTP over SSL from windows (not shitty sftp via ssh etc!) as explained on http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html (good variant 3: FTP_TLS ) I tried to learn from M2Crypto's ftpslib.py (uses OpenSSL - not Pythons SSL) and made a wrapper for ftplib.FTP using Pythons SSL. I wrap the cmd socket like: self.voidcmd('AUTH TLS') ssl = socket.ssl(self.sock, self.key_file, self.cert_file) import httplib self.sock = httplib.FakeSocket(self.sock, ssl) self.file = self.sock.makefile('rb') Everything works ok, if I don't SSL the data port connection, but only the If I SSL the data port connection too, it almosts work, but ... self.voidcmd('PBSZ 0') self.voidcmd('PROT P') wrap the data connection with SSL: ssl = socket.ssl(conn, self.key_file, self.cert_file) import httplib conn = httplib.FakeSocket(conn, ssl) than in retrbinary it hangs endless in the last 'return self.voidresp()'. all data of the retrieved file is already correctly in my basket! The ftp server just won't send the final '226 Transfer complete.' on the cmd socket. Why? def retrbinary(self, cmd, callback, blocksize=8192, rest=None): self.voidcmd('TYPE I') conn = self.transfercmd(cmd, rest) fp = conn.makefile('rb') while 1: #data = conn.recv(blocksize) data = fp.read() #blocksize) if not data: break callback(data) fp.close() conn.close() return self.voidresp() what could be reason? The server is a ProFTPD 1.2.9 Server. I debugged, that the underlying (Shared)socket of the conn object is really closed. (If I simly omit the self.voidresp(), I have one file in the box, but subsequent ftp communication on that connection is not anymore correct.) ---------------------------------------------------------------------- >Comment By: Armin Rigo (arigo) Date: 2006-11-20 11:33 Message: Logged In: YES user_id=4771 Originator: NO Martin, I think the rev 50844 is wrong. To start with, it goes clearly against the documentation for makefile() which states that both the socket and the pseudo-file can be closed independently. What httplib.py was doing was correct. I could write a whole essay about the twisted history of socket.py. It would boil down to: in r43746, Georg removed a comment that was partially out-of-date, but that was essential in explaining why there was no self._sock.close() in _socketobject.close(): because the original purpose of _socketobject was to implement dup(), so that multiple _socketobjects could refer to the same underlying _sock. The latter would close automagically when its reference counter dropped to zero. (This means that your check-in also made dup() stop working on all platforms.) The real OP's problem is that the _ssl object keeps a reference to the underlying _sock as well, as kxroberto pointed out. We need somewhere code that closes the _ssl object... For reference, PyPy - which doesn't have strong refcounting guarantees - added the equivalent of an explicit usage counter in the C socket object, and socket.py calls methods on its underlying object to increment and decrement that counter. It looks like a solution for CPython too - at least, relying on refcounting is bad, if only because - as you have just proved - it creates confusion. (Also, httplib/urllib have their own explicitly-refcounted wrappers...) ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-07-26 12:14 Message: Logged In: YES user_id=21627 This is now fixed in 50844. I won't backport it to 2.4, as it may cause working code to fail. For example, httplib would fail since it would already close the connection in getresponse, when the response object should still be able to read from the connection. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-07-03 12:03 Message: Logged In: YES user_id=21627 Can you please try the attached patch? It makes sure _socketobject.close really closes the socket, rather than relying on reference counting to close it. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-05-11 12:05 Message: Logged In: YES user_id=972995 Testing it with Python2.5a2, the problem is still there. Without the .shutdown(2) (or .shutdown(1)) patch to the httplib.SharedSocket (base for FakeSocket), the ftps example freezes on the cmd channel, because the SSL'ed data channel doesn't close/terminate --> FTPS server doesn't respond on the cmd channel. The ftps example is most specific to show the bug. Yet you can also easily blow up a HTTPS-server with this decent test code who only opens (bigger!) files and closes without reading everything: Python 2.5a2 (r25a2:45740, May 11 2006, 11:25:30) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type "help", "copyright", "credits" or "license" for more information. Robert's Interactive Python - TAB=complete import sys,os,re,string,time,glob,thread,pdb >>> import urllib >>> l=[] >>> for i in range(10): ... f=urllib.urlopen('https://srv/big-Python-2.5a2.tgz') ... f.close() ... l.append(f) ... >>> => in the (apache) servers ssl_engine_log you can see that connections remain open (until apache times out after 2 minutes) and lots of extra apache daemons are started! => f.close() doesn't really close the connection (until it is __del__'ed ) Trying around I found that the original undeleted f.fp._ssl is most probably the cause and holds the real socket open. a f.fp._sock.close() doesn't close also - but only when del f.fp._ssl is done. (only a f.fp._sock._sock.close() would force the close). The original fp is held in closures of .readline(s)/__iter__/next... -- I now tried an alternative patch (instead of the shutdown(2)-patch), which also so far seems to cure everything . Maybe thats the right solution for the bug: --- httplib.py.orig 2006-05-11 11:25:32.000000000 +0200 +++ httplib.py 2006-05-11 13:45:07.000000000 +0200 @@ -970,6 +970,7 @@ self._shared.decref() self._closed = 1 self._shared = None + self._ssl = None class SSLFile(SharedSocketClient): """File-like object wrapping an SSL socket.""" @@ -1085,6 +1086,7 @@ def close(self): SharedSocketClient.close(self) self._sock = self.__class__._closedsocket() + self._ssl = None def makefile(self, mode, bufsize=None): if mode != 'r' and mode != 'rb': -------------- In another application with SSL'ed SMTP connections there arose similar problems. I also worked around the problem in smtplib.py so far in a similar style: def close(self): self.realsock.shutdown(2) self.realsock.close() --- Yet, the right patch maybe (not tested extensively so far): --- Lib-orig/smtplib.py 2006-05-03 13:10:40.000000000 +0200 +++ Lib/smtplib.py 2006-05-11 13:50:12.000000000 +0200 @@ -142,6 +142,7 @@ sendall = send def close(self): + self.sslobj = None self.realsock.close() class SSLFakeFile: @@ -161,7 +162,7 @@ return str def close(self): - pass + self.sslobj = None def quoteaddr(addr): """Quote a subset of the email addresses defined by RFC 821. ------------------ -robert ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2005-09-24 19:45 Message: Logged In: YES user_id=972995 Now I managed to solve the problem for me with attached patch of httplib.py: a explicit shutdown ( 2 or 1 ) of the (faked) ssl'ed socket solves it. I still guess the ssl'ed socket (ssl dll) should do that auto on sock.close() Thus I leave it as a bug HERE. Right? [ I also have the hope, that this also solves the ssl-eof-errors with https (of some of my users; will see this in future) *** \usr\src\py24old/httplib.py Sat Sep 24 21:35:28 2005 --- httplib.py Sat Sep 24 21:37:48 2005 *************** class SharedSocket: *** 899,904 **** --- 899,905 ---- self._refcnt -= 1 assert self._refcnt >= 0 if self._refcnt == 0: + self.sock.shutdown(2) self.sock.close() def __del__(self): ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2005-09-24 19:06 Message: Logged In: YES user_id=972995 I retried that again with py2.4.1. The problem/bug is still there. In attachment I supplied a full FTPS client test_ftpslib.py with simple test function - ready to run into the problem: At the end of ftp.retrlines 'return self.voidresp()' freezes : waiting eternally for response bytes at the command port. the same at the end of .storelines after the data is transfered on the data port. My preliminary guess is still, that python's ssl has a severe (EOF?) problem closing a socket/connection correctly. obviously this problem doesn't show up with https because everything is done on one connection - no dependency on a correct socket/connect close signal. (from other https communication with some proxies in between my users get ssl-eof-error errors also. I still can't solve that bug too. this shows python's ssl has a severe EOF bug with complex https also - or cannot handle certain situations correct.) I learned the FTPS/TLS client from M2crypto's ftpslib. the only difference in (transposed) logic, that I can see is, that M2crpyto uses an additional line "conn.set_session(self.sock.get_session())" during setup of the data port ssl connection. I don't know what it is, pythons ssl doesn't have sucht "session"-functions, but I think it has no severe meaning.? Robert ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-12-22 05:14 Message: Logged In: YES user_id=357491 Since I believe this was fixed with the patch Tino mentions and Roberto has not replied, I am closing as fixed. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2004-08-16 23:18 Message: Logged In: YES user_id=357491 Is this still a problem for you, Roberto, with Python 2.4a2? ---------------------------------------------------------------------- Comment By: Tino Lange (tinolange) Date: 2004-07-10 22:30 Message: Logged In: YES user_id=212920 Hi Roberto! Today a patch for _ssl.c was checked in (see #945642) that might solve your problem, too. Could you please grab the *next* alpha (this will be Python 2.4 Alpha 2) and test and report afterwards if it is solved? Thanks for your help! Tino ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470 From noreply at sourceforge.net Mon Nov 20 16:27:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 07:27:06 -0800 Subject: [ python-Bugs-1599782 ] Segfault on bsddb.db.DB().type() Message-ID: Bugs item #1599782, was opened at 2006-11-20 15: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=1599782&group_id=5470 Please note that this 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 Private: No Submitted By: Rob Sanderson (azaroth42) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault on bsddb.db.DB().type() Initial Comment: Python interpreter exits with a Seg fault when trying to find the type of an unopened bsddb connection. Should check that the cxn is open, as per other functions in the library. [cheshire3 at helmsdeep ~]$ python2.5 Python 2.5 (r25:51908, Nov 20 2006, 15:09:48) [GCC 4.0.0 20050519 (Red Hat 4.0.0-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from bsddb.db import DB >>> cxn = DB() >>> cxn.type() Segmentation fault Thanks! -- Azaroth ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599782&group_id=5470 From noreply at sourceforge.net Mon Nov 20 18:07:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 09:07:21 -0800 Subject: [ python-Bugs-1595742 ] SocketServer allow_reuse_address checked in constructor Message-ID: Bugs item #1595742, was opened at 2006-11-13 11:54 Message generated for change (Comment added) made by parente You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595742&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Peter Parente (parente) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer allow_reuse_address checked in constructor Initial Comment: Python 2.4.3 (#1, Oct 1 2006, 18:00:19) [GCC 4.1.1 20060928 (Red Hat 4.1.1-28)] on linux2 The documentation in the SocketServer class indicates that the allow_reuse_address flag may be set on a SocketServer subclass *or instance.* However, the flag is read in a call to the server_bind() from the constructor of the server object. Therefore, setting the flag on a created instance has no effect. This is problematic when trying to set the flag on SimpleXMLRPCServer instances, for instance, which are often not subclassed. This flag should probably become one of the keyword arguments in the constructor of a SocketServer object. ---------------------------------------------------------------------- >Comment By: Peter Parente (parente) Date: 2006-11-20 12:07 Message: Logged In: YES user_id=624776 Originator: YES The SimpleXMLRPCServer class in SVN HEAD now has allow_reuse_address set to True by default. This mimics the implementation of the BaseHTTPServer class which also has it set to True. Therefore, this patch should probably not concentrate on just making allow_reuse_address flag accessible on instances via __init__. Instead, the patch should probably be for TCPServer and specify whether server_bind and server_activate are called automatically or not by the constructor. The default behavior will remain the same as it is now. Specifying False on this flag will allow a developer to set the various variables on a TCPServer server instance before invoking bind/activate manually. ---------------------------------------------------------------------- Comment By: Peter Parente (parente) Date: 2006-11-16 22:28 Message: Logged In: YES user_id=624776 Originator: YES Will do. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-15 12:34 Message: Logged In: YES user_id=849994 Originator: NO Would you want to work on a patch for this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595742&group_id=5470 From noreply at sourceforge.net Mon Nov 20 18:16:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 09:16:42 -0800 Subject: [ python-Bugs-1595742 ] SocketServer allow_reuse_address checked in constructor Message-ID: Bugs item #1595742, was opened at 2006-11-13 11:54 Message generated for change (Comment added) made by parente You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595742&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Peter Parente (parente) Assigned to: Nobody/Anonymous (nobody) Summary: SocketServer allow_reuse_address checked in constructor Initial Comment: Python 2.4.3 (#1, Oct 1 2006, 18:00:19) [GCC 4.1.1 20060928 (Red Hat 4.1.1-28)] on linux2 The documentation in the SocketServer class indicates that the allow_reuse_address flag may be set on a SocketServer subclass *or instance.* However, the flag is read in a call to the server_bind() from the constructor of the server object. Therefore, setting the flag on a created instance has no effect. This is problematic when trying to set the flag on SimpleXMLRPCServer instances, for instance, which are often not subclassed. This flag should probably become one of the keyword arguments in the constructor of a SocketServer object. ---------------------------------------------------------------------- >Comment By: Peter Parente (parente) Date: 2006-11-20 12:16 Message: Logged In: YES user_id=624776 Originator: YES Submitted as patch #1599845 in patch tracker. ---------------------------------------------------------------------- Comment By: Peter Parente (parente) Date: 2006-11-20 12:07 Message: Logged In: YES user_id=624776 Originator: YES The SimpleXMLRPCServer class in SVN HEAD now has allow_reuse_address set to True by default. This mimics the implementation of the BaseHTTPServer class which also has it set to True. Therefore, this patch should probably not concentrate on just making allow_reuse_address flag accessible on instances via __init__. Instead, the patch should probably be for TCPServer and specify whether server_bind and server_activate are called automatically or not by the constructor. The default behavior will remain the same as it is now. Specifying False on this flag will allow a developer to set the various variables on a TCPServer server instance before invoking bind/activate manually. ---------------------------------------------------------------------- Comment By: Peter Parente (parente) Date: 2006-11-16 22:28 Message: Logged In: YES user_id=624776 Originator: YES Will do. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-15 12:34 Message: Logged In: YES user_id=849994 Originator: NO Would you want to work on a patch for this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595742&group_id=5470 From noreply at sourceforge.net Mon Nov 20 19:10:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 10:10:25 -0800 Subject: [ python-Bugs-1599879 ] problem with socket.gethostname documentation Message-ID: Bugs item #1599879, was opened at 2006-11-20 19: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=1599879&group_id=5470 Please note that this 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 Private: No Submitted By: Malte Helmert (maltehelmert) Assigned to: Nobody/Anonymous (nobody) Summary: problem with socket.gethostname documentation Initial Comment: The socket.gethostname documentation contains the following note: "Note: gethostname() doesn't always return the fully qualified domain name; use gethostbyaddr(gethostname()) (see below)." However, the socket.gethostbyaddr documentation contains the following piece of information: "To find the fully qualified domain name, use the function getfqdn()." I suggest that the note in socket.gethostname be changed to: "Note: gethostname() doesn't always return the fully qualified domain name; use getfqdn() (see above)." ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599879&group_id=5470 From noreply at sourceforge.net Mon Nov 20 20:45:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 11:45:25 -0800 Subject: [ python-Bugs-1599931 ] Immediate Crash on Open Message-ID: Bugs item #1599931, was opened at 2006-11-20 13:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599931&group_id=5470 Please note that this 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 Private: No Submitted By: Farhymn (farhymn) Assigned to: Nobody/Anonymous (nobody) Summary: Immediate Crash on Open Initial Comment: Python 2.5 IDLE crashes -immediately- upon open, leaving enough time to hold down the enter button on the executable and only have the pythonw process show up one-at-a-time. This is version specific, as 2.4 Final worked fine. Now all applications cannot run. I made sure to uninstall 2.4 before installing 2.5, so it isn't a version conflict (as far as I can tell). Running Windows XP SP2 on an HP Laptop (paviliion dv4000) and am attempting to run the program OpenRPG+. Program can be provided for replication of test as necessary. Duplicate processes are not observed in Windows Task Manager and a complete uninstallation and installation of the Python 2.5 language provides the same unknown error. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599931&group_id=5470 From noreply at sourceforge.net Mon Nov 20 20:53:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 11:53:21 -0800 Subject: [ python-Bugs-1599931 ] Immediate Crash on Open Message-ID: Bugs item #1599931, was opened at 2006-11-20 13:45 Message generated for change (Comment added) made by farhymn You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599931&group_id=5470 Please note that this 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 Private: No Submitted By: Farhymn (farhymn) Assigned to: Nobody/Anonymous (nobody) Summary: Immediate Crash on Open Initial Comment: Python 2.5 IDLE crashes -immediately- upon open, leaving enough time to hold down the enter button on the executable and only have the pythonw process show up one-at-a-time. This is version specific, as 2.4 Final worked fine. Now all applications cannot run. I made sure to uninstall 2.4 before installing 2.5, so it isn't a version conflict (as far as I can tell). Running Windows XP SP2 on an HP Laptop (paviliion dv4000) and am attempting to run the program OpenRPG+. Program can be provided for replication of test as necessary. Duplicate processes are not observed in Windows Task Manager and a complete uninstallation and installation of the Python 2.5 language provides the same unknown error. ---------------------------------------------------------------------- >Comment By: Farhymn (farhymn) Date: 2006-11-20 13:53 Message: Logged In: YES user_id=1650037 Originator: YES (edit) Forgot to mention that the problem is pythonw.exe specific as well. Python DOS runs fine, I can only get it to register a token error by typing in the following at the prompt: 1234816587613289741-0152872349817230987 . ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599931&group_id=5470 From noreply at sourceforge.net Tue Nov 21 04:33:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 19:33:32 -0800 Subject: [ python-Bugs-1600152 ] mailbox: Maildir.get_folder does not inherit factory Message-ID: Bugs item #1600152, was opened at 2006-11-21 12: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=1600152&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Tetsuya Takatsuru (taka2ru) Assigned to: Nobody/Anonymous (nobody) Summary: mailbox: Maildir.get_folder does not inherit factory Initial Comment: mailbox.Maildir.get_folder does not inherit _factory. >>> import mailbox >>> >>> mbox = mailbox.Maildir('/home/xxx/Maildir', mailbox.MaildirMessage) >>> >>> subfolder = mbox.get_folder(mbox.list_folders()[0]) >>> >>> for key, mail in subfolder.iteritems(): >>> print mail.__class__ >>> break from this example, i got the following output: rfc822.Message 'mailbox.MaildirMessage' should be gotten instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600152&group_id=5470 From noreply at sourceforge.net Tue Nov 21 04:52:02 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 19:52:02 -0800 Subject: [ python-Bugs-1600157 ] [PATCH] Quitting The Interpreter Message-ID: Bugs item #1600157, was opened at 2006-11-20 21: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=1600157&group_id=5470 Please note that this message 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 Private: No Submitted By: Chris Carter (cdcarter) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] Quitting The Interpreter Initial Comment: When i type 'quit' in the interpreter, i get a nice little class and method yelling at me, instead of just quitting. PATCH: 
def setquit():

    class Quitter(object):
        def __init__(self, name):
            self.name = name
        def __repr__(self):
            quit()
        def __call__(self, code=None):
            # Shells like IDLE catch the SystemExit, but listen when their
            # stdin wrapper is closed.
            try:
                sys.stdin.close()
            except:
                pass
            raise SystemExit(code)
    __builtin__.quit = Quitter('quit')
    __builtin__.exit = Quitter('exit')
---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600157&group_id=5470 From noreply at sourceforge.net Tue Nov 21 04:52:22 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 19:52:22 -0800 Subject: [ python-Bugs-1600157 ] [PATCH] Quitting The Interpreter Message-ID: Bugs item #1600157, was opened at 2006-11-20 21:52 Message generated for change (Settings changed) made by cdcarter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600157&group_id=5470 Please note that this message 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: 9 Private: No Submitted By: Chris Carter (cdcarter) Assigned to: Nobody/Anonymous (nobody) Summary: [PATCH] Quitting The Interpreter Initial Comment: When i type 'quit' in the interpreter, i get a nice little class and method yelling at me, instead of just quitting. PATCH: 
def setquit():

    class Quitter(object):
        def __init__(self, name):
            self.name = name
        def __repr__(self):
            quit()
        def __call__(self, code=None):
            # Shells like IDLE catch the SystemExit, but listen when their
            # stdin wrapper is closed.
            try:
                sys.stdin.close()
            except:
                pass
            raise SystemExit(code)
    __builtin__.quit = Quitter('quit')
    __builtin__.exit = Quitter('exit')
---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600157&group_id=5470 From noreply at sourceforge.net Tue Nov 21 06:27:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 21:27:14 -0800 Subject: [ python-Bugs-1600182 ] Tix ComboBox entry is blank when not editable Message-ID: Bugs item #1600182, was opened at 2006-11-21 15: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=1600182&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tim Wegener (twegener) Assigned to: Martin v. L?wis (loewis) Summary: Tix ComboBox entry is blank when not editable Initial Comment: When setting editable=False for Tix.ComboBox, when selecting an item from the combo box, the selected item should appear in the entry field. In Windows this does not happen, and the entry field is dark grey and blank. When editable=True the label is visible. Problem occurs in: Python 2.3.5 (Windows) Python 2.4.4 (Windows) (the above appear to use tk 8.4) Works fine in: Python 2.2.2 (Red Hat 9) Python 2.3.5 (Red Hat 9) Python 2.4.1 (Red Hat 9) Python 2.5 (Red Hat 9) (all of the above with tk 8.3.5, tix 8.1.4) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600182&group_id=5470 From noreply at sourceforge.net Tue Nov 21 06:29:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 21:29:57 -0800 Subject: [ python-Bugs-1599782 ] Segfault on bsddb.db.DB().type() Message-ID: Bugs item #1599782, was opened at 2006-11-20 07:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599782&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Rob Sanderson (azaroth42) >Assigned to: Neal Norwitz (nnorwitz) Summary: Segfault on bsddb.db.DB().type() Initial Comment: Python interpreter exits with a Seg fault when trying to find the type of an unopened bsddb connection. Should check that the cxn is open, as per other functions in the library. [cheshire3 at helmsdeep ~]$ python2.5 Python 2.5 (r25:51908, Nov 20 2006, 15:09:48) [GCC 4.0.0 20050519 (Red Hat 4.0.0-8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from bsddb.db import DB >>> cxn = DB() >>> cxn.type() Segmentation fault Thanks! -- Azaroth ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-20 21:29 Message: Logged In: YES user_id=33168 Originator: NO Thanks for the bug report! Note: this also affects Python 2.4 and probably earlier. Committed revision 52811. (2.6) Committed revision 52812. (2.5) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599782&group_id=5470 From noreply at sourceforge.net Tue Nov 21 06:43:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 21:43:17 -0800 Subject: [ python-Bugs-1600182 ] Tix ComboBox entry is blank when not editable Message-ID: Bugs item #1600182, was opened at 2006-11-21 15:57 Message generated for change (Comment added) made by twegener You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600182&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tim Wegener (twegener) Assigned to: Martin v. L?wis (loewis) Summary: Tix ComboBox entry is blank when not editable Initial Comment: When setting editable=False for Tix.ComboBox, when selecting an item from the combo box, the selected item should appear in the entry field. In Windows this does not happen, and the entry field is dark grey and blank. When editable=True the label is visible. Problem occurs in: Python 2.3.5 (Windows) Python 2.4.4 (Windows) (the above appear to use tk 8.4) Works fine in: Python 2.2.2 (Red Hat 9) Python 2.3.5 (Red Hat 9) Python 2.4.1 (Red Hat 9) Python 2.5 (Red Hat 9) (all of the above with tk 8.3.5, tix 8.1.4) ---------------------------------------------------------------------- >Comment By: Tim Wegener (twegener) Date: 2006-11-21 16:13 Message: Logged In: YES user_id=434490 Originator: YES The following workaround does the job: entry = combobox.subwidget_list['entry'] entry.config(state='readonly') It appears that when doing ComboBox(editable=False) the Entry widget is being set to DISABLED rather than 'readonly'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600182&group_id=5470 From noreply at sourceforge.net Tue Nov 21 07:26:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 20 Nov 2006 22:26:00 -0800 Subject: [ python-Bugs-1599879 ] problem with socket.gethostname documentation Message-ID: Bugs item #1599879, was opened at 2006-11-20 10:10 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599879&group_id=5470 Please note that this 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 Private: No Submitted By: Malte Helmert (maltehelmert) >Assigned to: Neal Norwitz (nnorwitz) Summary: problem with socket.gethostname documentation Initial Comment: The socket.gethostname documentation contains the following note: "Note: gethostname() doesn't always return the fully qualified domain name; use gethostbyaddr(gethostname()) (see below)." However, the socket.gethostbyaddr documentation contains the following piece of information: "To find the fully qualified domain name, use the function getfqdn()." I suggest that the note in socket.gethostname be changed to: "Note: gethostname() doesn't always return the fully qualified domain name; use getfqdn() (see above)." ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-20 22:25 Message: Logged In: YES user_id=33168 Originator: NO Good catch! Thanks. Committed revision 52815. (2.6) Committed revision 52816. (2.5) (Probably affects all version back to 2.0 or so.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599879&group_id=5470 From noreply at sourceforge.net Tue Nov 21 09:15:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Nov 2006 00:15:36 -0800 Subject: [ python-Bugs-548661 ] os.popen w/o using the shell Message-ID: Bugs item #548661, was opened at 2002-04-25 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=548661&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Feature Request >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Ian Bicking (ianbicking) Assigned to: Nobody/Anonymous (nobody) Summary: os.popen w/o using the shell Initial Comment: I heard that there was an undocumented feature to the os.popen family, where instead of passing a command string as the first argument you could pass a list, as [path, arg1, arg2, ...], and circumvent any shell interpretation. I was disapointed to see that this was not so ("popen() argument 1 must be string, not list" ditto tuple) I believe this would be an excellent feature -- using the shell is a significant source of errors due to quoting, as well as a serious security concern. 95% of the time the shell is not required. The shell also introduces portability concerns (e.g., bug #512433) -- creating a Python shell is not necessary when the shell is usually superfluous anyway. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-21 00:15 Message: Logged In: YES user_id=33168 Originator: NO I agree this isn't required in popen since you can do it with the subprocess module. Closing. ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2005-04-19 09:45 Message: Logged In: YES user_id=210337 This may not matter enough to resolve now, with the advent of the subprocess module. ---------------------------------------------------------------------- Comment By: Peter ??strand (astrand) Date: 2003-11-01 08:29 Message: Logged In: YES user_id=344921 popen5 never uses the shell (http://www.lysator.liu.se/~astrand/popen5/) ---------------------------------------------------------------------- Comment By: Juli?n Mu?oz (julian69) Date: 2003-01-08 08:15 Message: Logged In: YES user_id=77756 Does this mean that giving a list to popen2 free us from taking care of the dangerous characters that could be interprated/escaped by the shell ??? I don't find any documentation about this feature !!! ---------------------------------------------------------------------- Comment By: Ian Bicking (ianbicking) Date: 2002-04-25 11:18 Message: Logged In: YES user_id=210337 I see you are correct. It would be nice if this feature was consistent across all popen*, and was also documented (and so also committed to with clear semantics) ---------------------------------------------------------------------- Comment By: Martin v. L??wis (loewis) Date: 2002-04-25 11:13 Message: Logged In: YES user_id=21627 This feature is indeed available in popen2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548661&group_id=5470 From noreply at sourceforge.net Tue Nov 21 09:21:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Nov 2006 00:21:37 -0800 Subject: [ python-Bugs-613222 ] memory leaks when importing posix module Message-ID: Bugs item #613222, was opened at 2002-09-23 07:27 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=613222&group_id=5470 Please note that this message 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: Out of Date Priority: 3 Private: No Submitted By: Neal Norwitz (nnorwitz) Assigned to: Guido van Rossum (gvanrossum) Summary: memory leaks when importing posix module Initial Comment: The attached program which calls Py_Initialize/Py_Finalize in a loop demonstrates a program which grows quite quickly. This bug effects 2.2.1+ and 2.3. valgrind reports that the memory is still reachable, but it seems like a memory leak and the process definitely grows. Compile the program with libpython, and run (./mem-test 100000). Make sure it can import site (which imports posix module). While the program is running, do a ps and watch it grow. If import site fails, the process will not grow. site.py can be as simple as import posix. I believe the problem is related to PyStructSequence_Fields for statfs. But haven't completely diagnosed the problem. As I learn more, I will add comments. To simply importing or not importing site, mem-test takes an optional 2nd argument which will enable/disable loading of site.py. ./mem-test 100000 1 will prevent import site. I hope this is understandable, even though the description wasn't clear. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-21 00:21 Message: Logged In: YES user_id=33168 Originator: YES The important parts of the patch have been applied. Py_Initialize/Py_Finalize in a loop is known to be an issue and is documented AFAIK. Closing. ---------------------------------------------------------------------- Comment By: Facundo Batista (facundobatista) Date: 2005-03-21 10:04 Message: Logged In: YES user_id=752496 Changed to 2.3 group. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-12-26 07:16 Message: Logged In: YES user_id=6380 I expect I will have no time to look into this further any time soon. But if you have fixes that clearly fix leaks, please check them in! (Shouldn't this be in the 2.3 group?) ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2002-09-24 17:37 Message: Logged In: YES user_id=33168 I'm mostly stuck. I haven't solved the problem, but I do have some more information. Attached is a patch to Object/structseq.c which fixes some problems if memory allocation fails. Also, I changed a PyInt_FromLong(1) to Py_True for __safe_for_unpickling__. Py_True could also be used in compile.c:: symtable_load_symbols replacing the variable: implicit. Some fields which I believe are leaking from the PyTypeObject are: tp_members, tp_dict, and tp_bases. However, there are more leaks. I think all the remaining leaks come from PyType_Ready(). For example, from add_operators(), PyDescr_NewWrapper(). I thought DECREFing tp_dict would free these, but it didn't seem to have any effect. Part of the problem is how should these values be cleaned up. Putting cleanup in PyStructSequence_InitType would guarantee the problem is fixed for all structseqs, but that doesn't seem like a good idea. This would assume the PyTypeObject passed in is initialized. This is true for static variables, but not for any other variables. If there's a new API for cleanup, all the users of structseq will need to use it. Perhaps, this is only an issue in the core. I don't know about extension modules. Finally, I suspect there may be more leaks outside of posix too. These seem to mostly come from _Py_ReadyTypes() called in pythonrun.c::Py_Initialize(). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-23 09:32 Message: Logged In: YES user_id=6380 This is a good use of your time. Thanks for looking into this! Assign back to me when you have a fix for review or a stumbling block. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=613222&group_id=5470 From noreply at sourceforge.net Tue Nov 21 10:04:31 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Nov 2006 01:04:31 -0800 Subject: [ python-Bugs-779976 ] docs missing 'trace' module Message-ID: Bugs item #779976, was opened at 2003-07-29 19:05 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779976&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: Python 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Andrew Dalke (dalke) Assigned to: Jeremy Hylton (jhylton) Summary: docs missing 'trace' module Initial Comment: The 'trace' module is new in Python 2.3. There is no mention of it in the module listing at http://www.python.org/ doc/2.3/modindex.html nor is it documented in the "undocumented modules" chapter at http://www.python.org/ doc/2.3/lib/undoc.html . (You would think as one of the coauthors for that module that I could be of help, but it's been about 4 years since I looked at it. :) ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-21 01:04 Message: Logged In: YES user_id=33168 Originator: NO It's listed in the 2.5 docs, so I'm closing: http://docs.python.org/dev/2.5/lib/trace-api.html ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2006-07-31 09:33 Message: Logged In: YES user_id=11375 I've updated the scripts/README in preparation for the 2.5b3 release. ---------------------------------------------------------------------- Comment By: Peter Hansen (phansen) Date: 2003-12-09 11:19 Message: Logged In: YES user_id=567267 A trivial related note: Tools/Scripts/README.txt still lists trace.py as though it were still there and not in Lib instead. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2003-10-16 06:17 Message: Logged In: YES user_id=6656 <prod> Armin and I were talking about factoring out the co_lnotab-frobbing code and were being hampered by not knowing what the code was trying to do... ---------------------------------------------------------------------- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2003-09-09 14:00 Message: Logged In: YES user_id=3066 Jeremy made this a module, so he's volunteered to write the LaTeX docs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=779976&group_id=5470 From noreply at sourceforge.net Tue Nov 21 10:08:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Nov 2006 01:08:40 -0800 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 nnorwitz 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 Private: No 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: Neal Norwitz (nnorwitz) Date: 2006-11-21 01:08 Message: Logged In: YES user_id=33168 Originator: NO I agree with Martin, closing. ---------------------------------------------------------------------- Comment By: Andrew I MacIntyre (aimacintyre) Date: 2006-09-10 00:14 Message: Logged In: YES user_id=250749 As of 2.5, the stack size for a thread can be set before the thread is created. Windows and Linux seem to default to generous thread stack sizes (1MB or more), other platforms are parsimonious by comparison (eg FreeBSD at 64kB). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-09 17:03 Message: Logged In: YES user_id=21627 I fail to see the problem. You have to change the recursion limit; if you do, you risk a crash, as the documentation says: http://docs.python.org/lib/module-sys.html "This should be done with care, because a too-high limit can lead to a crash." With an unmodified recursionlimit in 2.4.3 on Windows, I get the expected RuntimeError. If it causes a crash on some system, it just means that the default recursion limit is too high for that platform (however, we don't seem to have a confirmation that the default recursion limit is too large for this application on any platform for Python 2.4 or 2.5). It is quite common that the system provides the main thread with a larger stack space than any additional thread, so it is not surprising that the stack overflow is detected on some system when the code is run in the main thread, yet crashes in an additional thread. The default recursion limit should be the conservative minimum of what the system minimally guarantees for any thread. It seems that the original problem has been fixed (although nobody apparently has tested Python 2.4 or 2.5 on Solaris8); I suggest to close this as fixed again. ---------------------------------------------------------------------- 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 Tue Nov 21 10:19:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Nov 2006 01:19:21 -0800 Subject: [ python-Bugs-834452 ] python and lithuanian locales Message-ID: Bugs item #834452, was opened at 2003-11-02 00:41 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834452&group_id=5470 Please note that this 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 Private: No Submitted By: Mantas (mantaz) Assigned to: Nobody/Anonymous (nobody) Summary: python and lithuanian locales Initial Comment: python's locale.py file contains only one lithuanian locale Iso 8859-4 which is obsolete. Now almost all uses iso 8859-13. Lithuanian locale is called lt, and i think it must be named lt_lt. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-21 01:19 Message: Logged In: YES user_id=33168 Originator: NO Python 2.4 and earlier are not maintained. Since this is fixed in 2.5 I'm closing. ---------------------------------------------------------------------- Comment By: Serge Orlov (sorlov) Date: 2005-03-09 11:56 Message: Logged In: YES user_id=1235914 The fix is in Python 2.5. For 2.4 and 2.3 it is discussed in patch 1118341 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=834452&group_id=5470 From noreply at sourceforge.net Tue Nov 21 10:47:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Nov 2006 01:47:44 -0800 Subject: [ python-Bugs-1600157 ] [PATCH] Quitting The Interpreter Message-ID: Bugs item #1600157, was opened at 2006-11-21 03:52 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600157&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: None >Status: Closed >Resolution: Rejected Priority: 9 Private: No Submitted By: Chris Carter (cdcarter) >Assigned to: Michael Hudson (mwh) Summary: [PATCH] Quitting The Interpreter Initial Comment: When i type 'quit' in the interpreter, i get a nice little class and method yelling at me, instead of just quitting. PATCH: 
def setquit():

    class Quitter(object):
        def __init__(self, name):
            self.name = name
        def __repr__(self):
            quit()
        def __call__(self, code=None):
            # Shells like IDLE catch the SystemExit, but listen when their
            # stdin wrapper is closed.
            try:
                sys.stdin.close()
            except:
                pass
            raise SystemExit(code)
    __builtin__.quit = Quitter('quit')
    __builtin__.exit = Quitter('exit')
---------------------------------------------------------------------- >Comment By: Michael Hudson (mwh) Date: 2006-11-21 09:47 Message: Logged In: YES user_id=6656 Originator: NO Think what happens when you type 'print __builtin__.__dict__'. This has been proposed and rejected many times before, please search the python-dev archives for more. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600157&group_id=5470 From noreply at sourceforge.net Tue Nov 21 10:52:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Nov 2006 01:52:51 -0800 Subject: [ python-Bugs-1229788 ] Bus error in extension with gcc 3.3 Message-ID: Bugs item #1229788, was opened at 2005-06-29 08:43 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229788&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.3 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Gary Robinson (garyrob) Assigned to: Nobody/Anonymous (nobody) Summary: Bus error in extension with gcc 3.3 Initial Comment: This text contains a c module with 4 versions of the same extremely simple function. All they do is return a float double to python. On Windows I have received a report from someone who can built the module, imported it into Python, and ran it successfully. It has also been reported that there is no problem when the extension is compiled with gcc 4.0 on OS X. However, on OS X, if the extension is compiled with gcc 3.3, the 4th of the 4 function results in a bus error: >>> from check import * fun0() 411.0 >>> fun1() 534.30000000000007 >>> fun2() 411.0 >>> fun3() Bus error I originally reported this on the C++ sig's mail list. They suggested I try dev-python. Scott David Daniels on that list helped me refine some test cases and verified that they all worked on Windows. Along the way it was suggested that I post a bug report. So this is it. The code follows: #include "Python.h" static double value = 411.0; static PyObject * fun0(PyObject *self, PyObject *args) { if (!PyArg_ParseTuple(args, "", NULL)) return NULL; return Py_BuildValue("d", value); } static PyObject * fun1(PyObject *self, PyObject *args) { return Py_BuildValue("d", 1.3*value); } static PyObject * fun2(PyObject *self, PyObject *args) { return PyFloat_FromDouble(value); } static PyObject * fun3(PyObject *self, PyObject *args) { return Py_BuildValue("d", value); } static PyMethodDef TestMethods[] = { {"fun0", fun0, METH_VARARGS, "Read args and return value"}, {"fun1", fun1, METH_VARARGS, "Return value multiplied inline by 1.3"}, {"fun2", fun2, METH_VARARGS, "Return value using PyFloat_FromDouble"}, {"fun3", fun3, METH_VARARGS, "Return value using Py_BuildValue without reading args -- causes bus error on OS X Panther with XCode 1.5 installed"}, {NULL, NULL, 0, NULL} /* Sentinel */ }; PyMODINIT_FUNC initcheck(void) { PyObject *module; module = Py_InitModule3("check", TestMethods, "extension module with three functions."); if (module) { PyModule_AddStringConstant(module, "__version__", "0.02"); } } ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-21 01:52 Message: Logged In: YES user_id=33168 Originator: NO Closing due to no response. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-07-20 22:56 Message: Logged In: YES user_id=33168 Gary, care to comment? It's possible there was a bug fix or two related to alignment of floats. But if we can't reproduce this bug, we will have to close it. Please respond if you still have this problem within a week or two. ---------------------------------------------------------------------- Comment By: Darryl Dixon (esrever_otua) Date: 2005-07-12 21:36 Message: Logged In: YES user_id=567623 Bus errors are generally caused by unaligned memory accesses, or by attempts to read past the end of a file-descriptor (or something along those lines). This sounds like a gcc bug rather than a Python bug. Can I suggest changing your compiler flags and experimenting with things like different -O levels? (-O3, -O1, etc) to see if it makes a difference... Also, you may want to raise a bug with gcc (although I've no idea how seriously they would take it :( ). Finally, what version of gcc is Python compiled with on Panther? There may be a conflict there (once again, different optimisations might be the problem). Anyhow, just my random thoughts, D ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-07-01 20:13 Message: Logged In: YES user_id=593130 I understand that you got advice to post, but I strongly doubt that core Python code is involved for three reasons. 1. On the Unix I used, bus errors were much rarer and esoteric than segmentation violations (from bad pointers). But maybe BSD-derived OSX is different. 2. The only difference between fun1 that works and fun3 that doesn't, seems to be how the arg in computed. The receiving function only gets a value (which it copies) and does not know its history. 3. You report that upgrading the compiler fixes the problem. (So why not just do that?) If you want to experiment more, redo fun1 and fun3 with 'value' replaced by its literal value. Then redo again with value = 534.30000000000007 instead of 411 and change arg in fun1 to value/1.3 instead of 1.3*value. About stack trace: On unix (of 15 years ago), program crashes usually resulted in a file called 'core' added to either the startup or current working directory. A debugger program could extract a stack trace, which was more readable if the executable still had the symbol table attached and not stripped. I don't know equivalent for OSX, but I found it very helpful for debugging. ---------------------------------------------------------------------- Comment By: Gary Robinson (garyrob) Date: 2005-06-30 13:15 Message: Logged In: YES user_id=136420 It was reproduced by someone with Python 2.4 and gcc 3.3. So it is not my machine. As to closing it, a couple of people in the python C++ sig and python-dev suggested I post it here as a bug, so I did. I'm just doing what was requested of me. I don't mind if someone else feels it should be closed without doing anything about it, but I don't think everyone would agree with that action. As for stack trace, I don't know how to look for that. All I got was the "bus error" message. If you tell me what to look for I'll look for it. ---------------------------------------------------------------------- Comment By: Terry J. Reedy (tjreedy) Date: 2005-06-30 13:05 Message: Logged In: YES user_id=593130 Do you have any reason to think the bug is in Python rather than the older version of gcc? Or OSX? Or even your computer? If not, please consider closing. Does OSX give you a stack trace? If so,what is executing when the crash occurs? In fun3, Py_BuildValue, or somehow inbewteen? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229788&group_id=5470 From noreply at sourceforge.net Tue Nov 21 16:41:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Nov 2006 07:41:44 -0800 Subject: [ python-Feature Requests-1572210 ] help(x) for keywords too Message-ID: Feature Requests item #1572210, was opened at 2006-10-06 11:06 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: help(x) for keywords too Initial Comment: At the interactive prompt, help(object) is very useful. It would be nice if it also worked on keywords. """ >>> help(object) Help on class object in module __builtin__: class object | The most base type """ vs """ >>> help(with) SyntaxError: invalid syntax """ At the moment, the workaround is to open the documentation, pick a document that doesn't seem quite right (language reference?), go to the index, and look for the keyword. ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2006-11-21 10:41 Message: Logged In: YES user_id=764593 Originator: YES 1600491 contains a doc patch, which is basically just adding Tom Heller's advice on *how* to build to the error message. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-10-06 15:25 Message: Logged In: YES user_id=11105 > Is this likely to be a windows build issue? No. pydoc cannot use the .chm file. Either you should download the HTML files yourself, or you can compile the .chm file in a windows command shell (note that the decompilation runs in the background, and has no user interface): C:\Python24\Doc>hh -decompile . Python24.chm C:\Python24\Doc>dir *.chm Datentr?ger in Laufwerk C: ist ... Volumeseriennummer: ... Verzeichnis von C:\Python24\Doc 06.10.2006 21:23 3.732 about.html 06.10.2006 21:23 8.689 acks.html 06.10.2006 21:23 4.445 index.html 06.10.2006 21:23 35.525 modindex.html 4 Datei(en) 52.391 Bytes 0 Verzeichnis(se), 8.506.798.080 Bytes frei C:\Python24\Doc> The other HTML files are created in subdirectories, and help("if") now works. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-10-06 12:26 Message: Logged In: YES user_id=764593 No, it doesn't -- but putting the keyword in quotes does at least change the error message to saying that topic and keyword documentation is not available because the Python HTML documentation files could not be found. I'm using Windows XP, the 2.4 and 2.5 binaries from python.org, if I changed anything it was just the install directory to be Python2.5 (or 2.4 for 2.4)) The documentation (as a chm file) is found by the F1 key. Is this likely to be a windows build issue? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-10-06 11:59 Message: Logged In: YES user_id=849994 Doesn't help("if") work for you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470 From noreply at sourceforge.net Wed Nov 22 01:29:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Nov 2006 16:29:28 -0800 Subject: [ python-Bugs-1600860 ] --enable-shared links extensions to libpython statically Message-ID: Bugs item #1600860, was opened at 2006-11-22 01: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=1600860&group_id=5470 Please note that this 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 Private: No Submitted By: Marien Zwart (marienz) Assigned to: Nobody/Anonymous (nobody) Summary: --enable-shared links extensions to libpython statically Initial Comment: python 2.5 tries to link extension modules to libpython2.5 if python is compiled with --enable-shared (patch #1429775, bug #83279, svn r45232). To do this it adds -lpython2.5 and -L$PREFIX/lib/python2.5/config to the link command line. -lpython2.5 is fine, however the "config" directory it adds contains a static libpython2.5.a library. The libpython2.5.so I think it should be linking to is in $PREFIX/lib. The result is even a trivial extension pulls in (nearly) all of that library, so you get an extension that is over a megabyte in size where older pythons produce one of a few kilobytes. There is a comment on the referenced bug saying """ You can probably rely on libpythonxy.so ending up in $(DESTDIR)$(LIBDIR)/$(INSTSONAME), whose values you can retrieve from the installed Makefile (i.e. through distutils.config). """ so I think the patch that got applied does not do what was intended. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600860&group_id=5470 From noreply at sourceforge.net Wed Nov 22 07:57:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Nov 2006 22:57:13 -0800 Subject: [ python-Feature Requests-1599329 ] urllib(2) should allow automatic decoding by charset Message-ID: Feature Requests item #1599329, was opened at 2006-11-19 20:47 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1599329&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Erik Demaine (edemaine) Assigned to: Nobody/Anonymous (nobody) Summary: urllib(2) should allow automatic decoding by charset Initial Comment: Currently, urllib.urlopen(...).read() returns a string, not a unicode object. Ditto for urllib2. No attempt is made to decode the data using the charset encoding specified in the header ....info()['Content-Type']. Is it fair to assume that, in Python 3K, urllib....read() will return (Unicode) strings instead of bytes, automatically decoding according to the charset? Do you think we could expose this futuristic functionality in Python 2? I doubt we could change read() without breaking a lot of existing code that already does this decoding (e.g., http://zesty.ca/python/scrape.py), but perhaps a 'uread()' method could return a unicode object instead of a string. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-22 07:57 Message: Logged In: YES user_id=21627 Originator: NO I don't think urlopen(...).read() should return strings in Py3k, but instead it should return bytes - in general, resources retrieved are byte sequences (many are application/octet-stream). Making the return type depend on the resource being fetched is also unintuitive. It might be reasonable to have the user specified "binary" or "text" on urlopen() (just like regular open()). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1599329&group_id=5470 From noreply at sourceforge.net Wed Nov 22 08:09:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 21 Nov 2006 23:09:06 -0800 Subject: [ python-Bugs-1600860 ] --enable-shared links extensions to libpython statically Message-ID: Bugs item #1600860, was opened at 2006-11-22 01:29 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600860&group_id=5470 Please note that this 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 Private: No Submitted By: Marien Zwart (marienz) Assigned to: Nobody/Anonymous (nobody) Summary: --enable-shared links extensions to libpython statically Initial Comment: python 2.5 tries to link extension modules to libpython2.5 if python is compiled with --enable-shared (patch #1429775, bug #83279, svn r45232). To do this it adds -lpython2.5 and -L$PREFIX/lib/python2.5/config to the link command line. -lpython2.5 is fine, however the "config" directory it adds contains a static libpython2.5.a library. The libpython2.5.so I think it should be linking to is in $PREFIX/lib. The result is even a trivial extension pulls in (nearly) all of that library, so you get an extension that is over a megabyte in size where older pythons produce one of a few kilobytes. There is a comment on the referenced bug saying """ You can probably rely on libpythonxy.so ending up in $(DESTDIR)$(LIBDIR)/$(INSTSONAME), whose values you can retrieve from the installed Makefile (i.e. through distutils.config). """ so I think the patch that got applied does not do what was intended. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-22 08:09 Message: Logged In: YES user_id=21627 Originator: NO I can't reproduce the problem. Why do you think -L$PREFIX/lib/python2.5/config is added to the link command line? AFAICT, it never is. What operating system are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600860&group_id=5470 From noreply at sourceforge.net Wed Nov 22 12:50:30 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 03:50:30 -0800 Subject: [ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not work Message-ID: Bugs item #1579029, was opened at 2006-10-17 17:03 Message generated for change (Comment added) made by thurnerrupert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 >Status: Open Resolution: Wont Fix Priority: 5 Private: No Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Martin v. L?wis (loewis) Summary: --disable-sunaudiodev --disable-tk does not work Initial Comment: trying to disable sunaudiodev and tk does not really work in solaris. ./configure --prefix=/usr/local/Python-2.5 --enable- shared --disable-sunaudiodev --disable-tk building 'sunaudiodev' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/sunaudiodev.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/sunaudiodev.o /usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: sun/audioio.h: No such file or directory building '_tkinter' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -DWITH_APPINIT=1 - I/usr/openwin/include -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/_tkinter.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/_tkinter.o In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:96:23: X11/Xlib.h: No such file or directory In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:572: error: syntax error before "Window" /usr/local/include/tk.h:572: error: `Window' declared as function returning a function /usr/local/include/tk.h:575: error: syntax error before "XEvent" /usr/local/include/tk.h:584: error: syntax error before "Tk_ClassCreateProc" /usr/local/include/tk.h:592: error: syntax error before '}' token /usr/local/include/tk.h:678: error: syntax error before "Bool" is it possible to correct this or state clearly in the configure options how to disable it correctly? we also checked the Modules/Setup and both seems commented. ---------------------------------------------------------------------- >Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-22 12:50 Message: Logged In: YES user_id=1597584 Originator: YES may i open it again? there is a lot of builds on solaris without the core development environment, so assuming it is there is erronous. e.g. we build everything with standard gnu from e.g. sunfreeware.com. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 09:15 Message: Logged In: YES user_id=21627 Originator: NO Closing as "won't fix". There are no plans to implement --disable-sunaudiodev --disable-tk options to configure. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-06 18:51 Message: Logged In: YES user_id=21627 The component isn't vital. It shouldn't be relevant for building sunaudiodev whether an audio device is present in the system, as this device isn't necessary for *building* Python. Instead, presence of /usr/include/sys/audioio.h is necessary. I'm puzzled that this file isn't there (it is part of the core development environment, AFAIK); the build process assumes that the header is present if the system name is "sunos5". ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-06 10:23 Message: Logged In: YES user_id=1597584 i would appreciate if the build completes without errors. i won't care if it attemts to build, but it should figure out that the sunaudiodev is not there. to my knowledge servers do not need that component. and python should not need it too then. do you see any reason why these components are vital for python? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-04 00:25 Message: Logged In: YES user_id=21627 It doesn't build the modules, as it doesn't succeed when attempting to. Why do you want it not to attempt? ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-03 12:56 Message: Logged In: YES user_id=1597584 what do you suggest then to convince the build not to build it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-02 06:40 Message: Logged In: YES user_id=21627 Re: enable/disable: What makes you think "sunaudiodev" and "tk" are valid values for "FEATURE"? configure --help lists the valid values for FEATURE, namely universalsdk, framework, shared, profiling, toolbox-glue, ipv6, and unicode. Re: there is a compilation error. Sure, an error is reported. However, compilation should not fail because of that. Instead, compilation should complete successfully, and just end up not building these modules. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-02 00:31 Message: Logged In: YES user_id=1597584 and there is no X on the server. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:49 Message: Logged In: YES user_id=1597584 and what does that mean? Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:47 Message: Logged In: YES user_id=1597584 because there is a compilation error with both. sunaudio.h seems not to exist on our server, and tk gives other compilation errors. and i have no idea why i would need these modules on our server. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-17 17:43 Message: Logged In: YES user_id=21627 I fail to see a bug here. What makes you think --disable-sunaudiodev --disable-tk exist? ./configure --help does not claim they do. In fact, it is not possible to disable modules. Why do you want that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 From noreply at sourceforge.net Wed Nov 22 14:02:49 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 05:02:49 -0800 Subject: [ python-Bugs-1600860 ] --enable-shared links extensions to libpython statically Message-ID: Bugs item #1600860, was opened at 2006-11-22 01:29 Message generated for change (Comment added) made by marienz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600860&group_id=5470 Please note that this 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 Private: No Submitted By: Marien Zwart (marienz) Assigned to: Nobody/Anonymous (nobody) Summary: --enable-shared links extensions to libpython statically Initial Comment: python 2.5 tries to link extension modules to libpython2.5 if python is compiled with --enable-shared (patch #1429775, bug #83279, svn r45232). To do this it adds -lpython2.5 and -L$PREFIX/lib/python2.5/config to the link command line. -lpython2.5 is fine, however the "config" directory it adds contains a static libpython2.5.a library. The libpython2.5.so I think it should be linking to is in $PREFIX/lib. The result is even a trivial extension pulls in (nearly) all of that library, so you get an extension that is over a megabyte in size where older pythons produce one of a few kilobytes. There is a comment on the referenced bug saying """ You can probably rely on libpythonxy.so ending up in $(DESTDIR)$(LIBDIR)/$(INSTSONAME), whose values you can retrieve from the installed Makefile (i.e. through distutils.config). """ so I think the patch that got applied does not do what was intended. ---------------------------------------------------------------------- >Comment By: Marien Zwart (marienz) Date: 2006-11-22 14:02 Message: Logged In: YES user_id=857292 Originator: YES I can reproduce this by using either gentoo's python 2.5 or one I installed temporarily with ./configure --enable-shared --prefix $HOME/tmp/pytem, using a trivial distutils extension (I used http://dev.gentooexperimental.org/~marienz/ext.c and http://dev.gentooexperimental.org/~marienz/setup.py for testing). The relevant command that is run is: gcc -pthread -shared build/temp.linux-i686-2.5/ext.o -L/home/marienz/tmp/pytem/lib/python2.5/config -lpython2.5 -o build/lib.linux-i686-2.5/ext.so for the manually-configured python and something similar for gentoo's python. The code doing the adding was added by r45232 in svn. From the diff (svn di -r45231:45232 http://svn.python.org/projects/python/trunk/Lib/distutils/command/build_ext.py) with some extra context added: - if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos': + if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos' or \ + (sys.platform.startswith('linux') and + sysconfig.get_config_var('Py_ENABLE_SHARED')): if string.find(sys.executable, sys.exec_prefix) != -1: # building third party extensions self.library_dirs.append(os.path.join(sys.prefix, "lib", "python" + get_python_version(), "config")) (that is around line 188 of Lib/distutils/command/build_ext.py) sys.platform on this host is linux2 and as far as I can tell Py_ENABLE_SHARED is true if --enable-shared is passed to configure. If you need any more information please ask. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-22 08:09 Message: Logged In: YES user_id=21627 Originator: NO I can't reproduce the problem. Why do you think -L$PREFIX/lib/python2.5/config is added to the link command line? AFAICT, it never is. What operating system are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600860&group_id=5470 From noreply at sourceforge.net Wed Nov 22 19:50:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 10:50:09 -0800 Subject: [ python-Feature Requests-1185383 ] Make bisect.* functions accept an optional compare function Message-ID: Feature Requests item #1185383, was opened at 2005-04-18 19:26 Message generated for change (Comment added) made by minmax You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1185383&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Marcin Ciura (mciura) Assigned to: Nobody/Anonymous (nobody) Summary: Make bisect.* functions accept an optional compare function Initial Comment: The usability of bisect.bisect_right, bisect.bisect_left, bisect.insort_right and bisect.insort_left would increase if they accepted an optional less_than function to compare the keys. Here is my use case: I have a sorted list of reversed words and a parallel list of flags associated with these words (taken from ispell). The list of reversed words is the one searched; the flags are the result of a search. Issue #1: Now I cannot use simply a list of tuples (rev_word,flags) and a custom less_than function that compares only the first elements of two tuples. Issue #2: When a word is not found in the list, I'd like to make an educated guess as to its flags (this makes more sense in non-English languages, where e.g. infinitives have a special ending), using bisect_left and bisect_right: from bisect import * less_than = lambda x,y: x[:3] [...] but it could be a significant benefit for other functions that are expensive to compute (because repeated calls to bisect will access the lt function more than once). > Each subsequect call to bisect() would need to repeat those calls for a log(N) subset of the data. Which is exactly *why* I'm suggesting the key argument: to save those extra calls to the key function. Since that sounds counter-intuitive, let me explain: one sorts (origkey(item), item) pairs, the bisects with key=itemgetter(0), not calling the expensive origkey. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-06-03 01:25 Message: Logged In: YES user_id=80475 Overall, I'm -1 on this RFE. The comparison to nsmallest() and nlargest() is inaccurate. They run start-to-finish in one function call. The other heapq methods do not use key functions because they have to leave the original data structure unmolested between calls; hence, there is no ability to limit the key function calls to one per record. Likewise, with this request, the key function calls get wasted. The sort() method calls key() for every record and tosses the result afterwards. Each subsequect call to bisect() would need to repeat those calls for a log(N) subset of the data. Hence, accepting this request would create an API that encourages a wasteful design. ---------------------------------------------------------------------- Comment By: Jonas K?lker (jonaskoelker) Date: 2005-04-28 20:13 Message: Logged In: YES user_id=1153395 In a similar vein, I'd like to see that a `key' keyword argument was added to bisect.* (and perhaps `reversed' too)--it's really annoying to sort something by (not __lt__) and not be able to bsearch it. It got added to min/max and heapq.n(smallest|largest) in 2.5 fwiw ;) ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2005-04-18 20:09 Message: Logged In: YES user_id=80475 A few thoughts: * If bisect provided an optional lt argument, it would still not be thread-safe. The code for the lt function can call arbitrary Python code that runs through the eval-loop and is hence subject to a thread-switch. * An advantage of the class wrapper approach is that the prefix function gets computed just once per word. This is not a big deal for the specific case of [:3], but it could be a significant benefit for other functions that are expensive to compute (because repeated calls to bisect will access the lt function more than once). * My own approach to the particular use case would be to map prefixes to a list of revwords or (revword, flag) pairs: d = dict(abb=['abbc'], abc=['abcaa', 'abcdd', 'abcss'], abd=['abdf']) This gives O(1) lookup time and limits the calls to the prefix function to once per word. Will leave this request open as it may yet be a good idea. My concern is that it will clutter the code and the API for only a small benefit. Also, I'm looking at a more general purpose solution that would make this feature request moot. This idea is to create a fast comparison decorator class used like this: dwordlist = map(ComparisonDecorator(lambda x: x[:3]), wordlist) lp = bisect_left(dwordlist, given_rev_word) rp = bisect_right(dwordlist, given_rev_word) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1185383&group_id=5470 From noreply at sourceforge.net Wed Nov 22 20:15:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 11:15:29 -0800 Subject: [ python-Bugs-1571754 ] Building using Sleepycat db 4.5.20 is broken Message-ID: Bugs item #1571754, was opened at 2006-10-05 21:31 Message generated for change (Comment added) made by juedau You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571754&group_id=5470 Please note that this 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 Private: No Submitted By: Robert Scheck (robert-scheck) Assigned to: Nobody/Anonymous (nobody) Summary: Building using Sleepycat db 4.5.20 is broken Initial Comment: Using latest Sleepycat db 4.5.20, I'm getting the following result during make of python 2.5: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -I./Include -fPIC - DPy_BUILD_CORE -I/usr/include/db4 -c ./Modules/_bsddb. c -o Modules/_bsddb.o ./Modules/_bsddb.c: In function 'DBEnv_set_lk_max': ./Modules/_bsddb.c:4142: error: 'DB_ENV' has no member named 'set_lk_max' ./Modules/_bsddb.c: In function 'init_bsddb': ./Modules/_bsddb.c:5838: error: 'DB_CACHED_COUNTS' undeclared (first use in this function) ./Modules/_bsddb.c:5838: error: (Each undeclared identifier is reported only once ./Modules/_bsddb.c:5838: error: for each function it appears in.) ./Modules/_bsddb.c:5873: error: 'DB_RECORDCOUNT' undeclared (first use in this function) make: *** [Modules/_bsddb.o] Error 1 ---------------------------------------------------------------------- Comment By: sdkfsdf (juedau) Date: 2006-11-22 19:15 Message: Logged In: YES user_id=1627035 Originator: NO Didn't work for me. Sure, _bsddb.so can be linked against db 4.5.20 with your patch, but some of the tests from bsddb/test are crashing. Seems that we have to wait for official support. Tested with Python 2.5. ---------------------------------------------------------------------- Comment By: Robert Scheck (robert-scheck) Date: 2006-10-07 19:11 Message: Logged In: YES user_id=203809 The attached patches are solving the problems for me and should be the correct fix when reading Sleepycat's upgrade documentation... ---------------------------------------------------------------------- Comment By: Robert Scheck (robert-scheck) Date: 2006-10-05 21:34 Message: Logged In: YES user_id=203809 Ah, python 2.4.3 has the same problem plus further errors: ./Modules/_bsddb.c: In function 'DB_length': ./Modules/_bsddb.c:2453: error: 'DB_CACHED_COUNTS' undeclared (first use in this function) ./Modules/_bsddb.c:2453: error: (Each undeclared identifier is reported only once ./Modules/_bsddb.c:2453: error: for each function it appears in.) ./Modules/_bsddb.c: In function 'DBEnv_set_lk_max': ./Modules/_bsddb.c:3811: error: 'DB_ENV' has no member named 'set_lk_max' ./Modules/_bsddb.c: In function 'init_bsddb': ./Modules/_bsddb.c:5004: error: 'DB_CACHED_COUNTS' undeclared (first use in this function) ./Modules/_bsddb.c:5039: error: 'DB_RECORDCOUNT' undeclared (first use in this function) make: *** [Modules/_bsddb.o] Error 1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1571754&group_id=5470 From noreply at sourceforge.net Wed Nov 22 22:04:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 13:04:15 -0800 Subject: [ python-Bugs-1601399 ] urllib2 does not close sockets properly Message-ID: Bugs item #1601399, was opened at 2006-11-23 08: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=1601399&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Brendan Jurd (direvus) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 does not close sockets properly Initial Comment: Python 2.5 (release25-maint, Oct 29 2006, 12:44:11) [GCC 4.1.2 20061026 (prerelease) (Debian 4.1.1-18)] on linux2 I first noticed this when a program of mine (which makes a brief HTTPS connection every 20 seconds) started having some weird crashes. It turned out that the process had a massive number of file descriptors open. I did some debugging, and it became clear that the program was opening two file descriptors for every HTTPS connection it made with urllib2, and it wasn't closing them, even though I was reading all data from the response objects and then explictly calling close() on them. I found I could easily reproduce the behaviour using the interactive console. Try this while keeping an eye on the file descriptors held open by the python process: To begin with, the process will have the usual FDs 0, 1 and 2 open for std(in|out|err), plus one other. >>> import urllib2 >>> f = urllib2.urlopen("http://www.google.com") Now at this point the process has opened two more sockets. >>> f.read() [... HTML ensues ...] >>> f.close() The two extra sockets are still open. >>> del f The two extra sockets are STILL open. >>> f = urllib2.urlopen("http://www.python.org") >>> f.read() [...] >>> f.close() And now we have a total of four abandoned sockets open. It's not until you terminate the process entirely, or the OS (eventually) closes the socket on idle timeout, that they are closed. Note that if you do the same thing with httplib, the sockets are properly closed: >>> import httplib >>> c = httlib.HTTPConnection("www.google.com", 80) >>> c.connect() A socket has been opened. >>> c.putrequest("GET", "/") >>> c.endheaders() >>> r = c.getresponse() >>> r.read() [...] >>> r.close() And the socket has been closed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601399&group_id=5470 From noreply at sourceforge.net Wed Nov 22 22:53:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 13:53:37 -0800 Subject: [ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not work Message-ID: Bugs item #1579029, was opened at 2006-10-17 17:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: Wont Fix Priority: 5 Private: No Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Martin v. L?wis (loewis) Summary: --disable-sunaudiodev --disable-tk does not work Initial Comment: trying to disable sunaudiodev and tk does not really work in solaris. ./configure --prefix=/usr/local/Python-2.5 --enable- shared --disable-sunaudiodev --disable-tk building 'sunaudiodev' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/sunaudiodev.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/sunaudiodev.o /usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: sun/audioio.h: No such file or directory building '_tkinter' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -DWITH_APPINIT=1 - I/usr/openwin/include -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/_tkinter.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/_tkinter.o In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:96:23: X11/Xlib.h: No such file or directory In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:572: error: syntax error before "Window" /usr/local/include/tk.h:572: error: `Window' declared as function returning a function /usr/local/include/tk.h:575: error: syntax error before "XEvent" /usr/local/include/tk.h:584: error: syntax error before "Tk_ClassCreateProc" /usr/local/include/tk.h:592: error: syntax error before '}' token /usr/local/include/tk.h:678: error: syntax error before "Bool" is it possible to correct this or state clearly in the configure options how to disable it correctly? we also checked the Modules/Setup and both seems commented. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-22 22:53 Message: Logged In: YES user_id=21627 Originator: NO You still haven't demonstrated a problem. Compiling Python produces some error messages, sure, but does the resulting Python binary actually work or not? If it works, what is the problem? That you appreciate not to see error messages does not make it a bug. You cannot build Python *at all* with just the standard gnu from sunfreeware.com. You do need system header files, and those are not provided by GCC. So if you have header files, where did you get them from? ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-22 12:50 Message: Logged In: YES user_id=1597584 Originator: YES may i open it again? there is a lot of builds on solaris without the core development environment, so assuming it is there is erronous. e.g. we build everything with standard gnu from e.g. sunfreeware.com. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 09:15 Message: Logged In: YES user_id=21627 Originator: NO Closing as "won't fix". There are no plans to implement --disable-sunaudiodev --disable-tk options to configure. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-06 18:51 Message: Logged In: YES user_id=21627 The component isn't vital. It shouldn't be relevant for building sunaudiodev whether an audio device is present in the system, as this device isn't necessary for *building* Python. Instead, presence of /usr/include/sys/audioio.h is necessary. I'm puzzled that this file isn't there (it is part of the core development environment, AFAIK); the build process assumes that the header is present if the system name is "sunos5". ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-06 10:23 Message: Logged In: YES user_id=1597584 i would appreciate if the build completes without errors. i won't care if it attemts to build, but it should figure out that the sunaudiodev is not there. to my knowledge servers do not need that component. and python should not need it too then. do you see any reason why these components are vital for python? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-04 00:25 Message: Logged In: YES user_id=21627 It doesn't build the modules, as it doesn't succeed when attempting to. Why do you want it not to attempt? ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-03 12:56 Message: Logged In: YES user_id=1597584 what do you suggest then to convince the build not to build it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-02 06:40 Message: Logged In: YES user_id=21627 Re: enable/disable: What makes you think "sunaudiodev" and "tk" are valid values for "FEATURE"? configure --help lists the valid values for FEATURE, namely universalsdk, framework, shared, profiling, toolbox-glue, ipv6, and unicode. Re: there is a compilation error. Sure, an error is reported. However, compilation should not fail because of that. Instead, compilation should complete successfully, and just end up not building these modules. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-02 00:31 Message: Logged In: YES user_id=1597584 and there is no X on the server. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:49 Message: Logged In: YES user_id=1597584 and what does that mean? Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:47 Message: Logged In: YES user_id=1597584 because there is a compilation error with both. sunaudio.h seems not to exist on our server, and tk gives other compilation errors. and i have no idea why i would need these modules on our server. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-17 17:43 Message: Logged In: YES user_id=21627 I fail to see a bug here. What makes you think --disable-sunaudiodev --disable-tk exist? ./configure --help does not claim they do. In fact, it is not possible to disable modules. Why do you want that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 From noreply at sourceforge.net Thu Nov 23 03:38:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 18:38:36 -0800 Subject: [ python-Bugs-1601501 ] utf_8_sig decode fails with buffer input Message-ID: Bugs item #1601501, was opened at 2006-11-23 02: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=1601501&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: bazwal (bazwal) Assigned to: Nobody/Anonymous (nobody) Summary: utf_8_sig decode fails with buffer input Initial Comment: when the decode function in encodings.utf_8_sig receives a buffer object, it fails because it tries to check for a bom using startswith: >>> unicode('\xef\xbb\xbf', 'utf_8_sig') Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.5/encodings/utf_8_sig.py", line 19, in decode if input.startswith(codecs.BOM_UTF8): AttributeError: 'buffer' object has no attribute 'startswith' the test should be changed to: if input[:3] == codecs.BOM_UTF8: ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601501&group_id=5470 From noreply at sourceforge.net Thu Nov 23 05:00:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 20:00:29 -0800 Subject: [ python-Bugs-1601501 ] utf_8_sig decode fails with buffer input Message-ID: Bugs item #1601501, was opened at 2006-11-23 03:38 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601501&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: bazwal (bazwal) Assigned to: Nobody/Anonymous (nobody) Summary: utf_8_sig decode fails with buffer input Initial Comment: when the decode function in encodings.utf_8_sig receives a buffer object, it fails because it tries to check for a bom using startswith: >>> unicode('\xef\xbb\xbf', 'utf_8_sig') Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.5/encodings/utf_8_sig.py", line 19, in decode if input.startswith(codecs.BOM_UTF8): AttributeError: 'buffer' object has no attribute 'startswith' the test should be changed to: if input[:3] == codecs.BOM_UTF8: ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-11-23 05:00 Message: Logged In: YES user_id=89016 Originator: NO Can you provide a test that fails? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601501&group_id=5470 From noreply at sourceforge.net Thu Nov 23 06:04:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 21:04:52 -0800 Subject: [ python-Bugs-1601501 ] utf_8_sig decode fails with buffer input Message-ID: Bugs item #1601501, was opened at 2006-11-23 03:38 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601501&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: bazwal (bazwal) Assigned to: Nobody/Anonymous (nobody) Summary: utf_8_sig decode fails with buffer input Initial Comment: when the decode function in encodings.utf_8_sig receives a buffer object, it fails because it tries to check for a bom using startswith: >>> unicode('\xef\xbb\xbf', 'utf_8_sig') Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.5/encodings/utf_8_sig.py", line 19, in decode if input.startswith(codecs.BOM_UTF8): AttributeError: 'buffer' object has no attribute 'startswith' the test should be changed to: if input[:3] == codecs.BOM_UTF8: ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-11-23 06:04 Message: Logged In: YES user_id=89016 Originator: NO Oops, I missed your stacktrace. Fixed in r52826. (A better fix might be to add startswith() to buffer). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-23 05:00 Message: Logged In: YES user_id=89016 Originator: NO Can you provide a test that fails? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601501&group_id=5470 From noreply at sourceforge.net Thu Nov 23 06:05:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 21:05:05 -0800 Subject: [ python-Bugs-1601501 ] utf_8_sig decode fails with buffer input Message-ID: Bugs item #1601501, was opened at 2006-11-23 03:38 Message generated for change (Settings changed) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601501&group_id=5470 Please note that this message will contain 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: Accepted Priority: 5 Private: No Submitted By: bazwal (bazwal) Assigned to: Nobody/Anonymous (nobody) Summary: utf_8_sig decode fails with buffer input Initial Comment: when the decode function in encodings.utf_8_sig receives a buffer object, it fails because it tries to check for a bom using startswith: >>> unicode('\xef\xbb\xbf', 'utf_8_sig') Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.5/encodings/utf_8_sig.py", line 19, in decode if input.startswith(codecs.BOM_UTF8): AttributeError: 'buffer' object has no attribute 'startswith' the test should be changed to: if input[:3] == codecs.BOM_UTF8: ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-23 06:04 Message: Logged In: YES user_id=89016 Originator: NO Oops, I missed your stacktrace. Fixed in r52826. (A better fix might be to add startswith() to buffer). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-23 05:00 Message: Logged In: YES user_id=89016 Originator: NO Can you provide a test that fails? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601501&group_id=5470 From noreply at sourceforge.net Thu Nov 23 06:06:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 21:06:58 -0800 Subject: [ python-Bugs-1601501 ] utf_8_sig decode fails with buffer input Message-ID: Bugs item #1601501, was opened at 2006-11-23 03:38 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601501&group_id=5470 Please note that this message will contain 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: Accepted Priority: 5 Private: No Submitted By: bazwal (bazwal) Assigned to: Nobody/Anonymous (nobody) Summary: utf_8_sig decode fails with buffer input Initial Comment: when the decode function in encodings.utf_8_sig receives a buffer object, it fails because it tries to check for a bom using startswith: >>> unicode('\xef\xbb\xbf', 'utf_8_sig') Traceback (most recent call last): File "", line 1, in File "/usr/local/lib/python2.5/encodings/utf_8_sig.py", line 19, in decode if input.startswith(codecs.BOM_UTF8): AttributeError: 'buffer' object has no attribute 'startswith' the test should be changed to: if input[:3] == codecs.BOM_UTF8: ---------------------------------------------------------------------- >Comment By: Walter D?rwald (doerwalter) Date: 2006-11-23 06:06 Message: Logged In: YES user_id=89016 Originator: NO Fixed in r52827 for the 2.5 branch ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-23 06:04 Message: Logged In: YES user_id=89016 Originator: NO Oops, I missed your stacktrace. Fixed in r52826. (A better fix might be to add startswith() to buffer). ---------------------------------------------------------------------- Comment By: Walter D?rwald (doerwalter) Date: 2006-11-23 05:00 Message: Logged In: YES user_id=89016 Originator: NO Can you provide a test that fails? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601501&group_id=5470 From noreply at sourceforge.net Thu Nov 23 09:20:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Nov 2006 00:20:56 -0800 Subject: [ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not work Message-ID: Bugs item #1579029, was opened at 2006-10-17 17:03 Message generated for change (Comment added) made by thurnerrupert You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: Wont Fix Priority: 5 Private: No Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Martin v. L?wis (loewis) Summary: --disable-sunaudiodev --disable-tk does not work Initial Comment: trying to disable sunaudiodev and tk does not really work in solaris. ./configure --prefix=/usr/local/Python-2.5 --enable- shared --disable-sunaudiodev --disable-tk building 'sunaudiodev' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/sunaudiodev.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/sunaudiodev.o /usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: sun/audioio.h: No such file or directory building '_tkinter' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -DWITH_APPINIT=1 - I/usr/openwin/include -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/_tkinter.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/_tkinter.o In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:96:23: X11/Xlib.h: No such file or directory In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:572: error: syntax error before "Window" /usr/local/include/tk.h:572: error: `Window' declared as function returning a function /usr/local/include/tk.h:575: error: syntax error before "XEvent" /usr/local/include/tk.h:584: error: syntax error before "Tk_ClassCreateProc" /usr/local/include/tk.h:592: error: syntax error before '}' token /usr/local/include/tk.h:678: error: syntax error before "Bool" is it possible to correct this or state clearly in the configure options how to disable it correctly? we also checked the Modules/Setup and both seems commented. ---------------------------------------------------------------------- >Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-23 09:20 Message: Logged In: YES user_id=1597584 Originator: YES which header files do you mean? the sun/audioio.h header file e.g. is not there, but standard sun header files of course are there. it is though possible to get a running python. but i'm unsure what works and what not, so you could classify it as "cleanup" too, if you prefer. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-22 22:53 Message: Logged In: YES user_id=21627 Originator: NO You still haven't demonstrated a problem. Compiling Python produces some error messages, sure, but does the resulting Python binary actually work or not? If it works, what is the problem? That you appreciate not to see error messages does not make it a bug. You cannot build Python *at all* with just the standard gnu from sunfreeware.com. You do need system header files, and those are not provided by GCC. So if you have header files, where did you get them from? ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-22 12:50 Message: Logged In: YES user_id=1597584 Originator: YES may i open it again? there is a lot of builds on solaris without the core development environment, so assuming it is there is erronous. e.g. we build everything with standard gnu from e.g. sunfreeware.com. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 09:15 Message: Logged In: YES user_id=21627 Originator: NO Closing as "won't fix". There are no plans to implement --disable-sunaudiodev --disable-tk options to configure. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-06 18:51 Message: Logged In: YES user_id=21627 The component isn't vital. It shouldn't be relevant for building sunaudiodev whether an audio device is present in the system, as this device isn't necessary for *building* Python. Instead, presence of /usr/include/sys/audioio.h is necessary. I'm puzzled that this file isn't there (it is part of the core development environment, AFAIK); the build process assumes that the header is present if the system name is "sunos5". ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-06 10:23 Message: Logged In: YES user_id=1597584 i would appreciate if the build completes without errors. i won't care if it attemts to build, but it should figure out that the sunaudiodev is not there. to my knowledge servers do not need that component. and python should not need it too then. do you see any reason why these components are vital for python? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-04 00:25 Message: Logged In: YES user_id=21627 It doesn't build the modules, as it doesn't succeed when attempting to. Why do you want it not to attempt? ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-03 12:56 Message: Logged In: YES user_id=1597584 what do you suggest then to convince the build not to build it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-02 06:40 Message: Logged In: YES user_id=21627 Re: enable/disable: What makes you think "sunaudiodev" and "tk" are valid values for "FEATURE"? configure --help lists the valid values for FEATURE, namely universalsdk, framework, shared, profiling, toolbox-glue, ipv6, and unicode. Re: there is a compilation error. Sure, an error is reported. However, compilation should not fail because of that. Instead, compilation should complete successfully, and just end up not building these modules. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-02 00:31 Message: Logged In: YES user_id=1597584 and there is no X on the server. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:49 Message: Logged In: YES user_id=1597584 and what does that mean? Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:47 Message: Logged In: YES user_id=1597584 because there is a compilation error with both. sunaudio.h seems not to exist on our server, and tk gives other compilation errors. and i have no idea why i would need these modules on our server. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-17 17:43 Message: Logged In: YES user_id=21627 I fail to see a bug here. What makes you think --disable-sunaudiodev --disable-tk exist? ./configure --help does not claim they do. In fact, it is not possible to disable modules. Why do you want that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 From noreply at sourceforge.net Thu Nov 23 09:52:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Nov 2006 00:52:09 -0800 Subject: [ python-Bugs-1601607 ] using python extension(wxPython) in c Message-ID: Bugs item #1601607, was opened at 2006-11-23 08: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=1601607&group_id=5470 Please note that this 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 Private: No Submitted By: jolleydtan (jolleydtan) Assigned to: Nobody/Anonymous (nobody) Summary: using python extension(wxPython) in c Initial Comment: hello,all. i am confronting with a weird problem, almost forcing to die,the feeling is miserable, so pls help me. here is a python application named "helloWorld",a simple gui application, assisted with wxPython. from wxPython.wx import * class myApp(wxApp): def OnInit(self): frame = wxFrame(NULL,-1,"hello,world!"); frame.Show(true) self.SetTopWindow(frame) return true app = myApp() app.MainLoop() also sorry for my unsmart code, which i should import wx not wxPython.wx. and i want to use the simplest way to combine with c.so i use: #include "python.h" #include "wx/wxPython/wxPython.h" #include using namespace std; int main() { Py_Initialize(); if(!Py_IsInitialized()) { cerr << "hello,world!"<< endl; return -1; } PyRun_SimpleString("from wxPython.wx import *"); PyRun_SimpleString("class myApp(wxApp):"); PyRun_SimpleString(" def OnInit(self):"); PyRun_SimpleString(" frame = wxFrame(NULL,-1,"hello,world!")"); PyRun_SimpleString(" frame.Show(true)"); PyRun_SimpleString(" self.SetTopWindow(frame)"); PyRun_SimpleString(" return true"); PyRun_SimpleString("app = myApp()"); PyRun_SimpleString("app.MainLoop()"); Py_Finalize(); return 0; } in addition, to make this work, i have configure something like this: add the wxpython include/library files in vc. includes: c:\wxPython-src-2.6.3.3\wxPython\include. c:\python24\include\wx(it is the product of building wxPython) also the python include here. c:\python24\include libraries: c:\wxPython-src-2.6.3.3\lib\vc_dll(the build product of wxWidgets) c:\wxPython-src-2.6.3.3\wxPython\wxPython c:\python24\libs to supplement the problem, i install wxPython from source code,and i have gotten three files,all of which will be uploaded here. and both them can pass the build process,but get "detected memory leaks and dump objects"in the run process. i figure that it has great memory leaks when loading certain symbols,like wxmsw26ud.lib or such,while other lib are not loaded "no symbol loaded!" but i donot know why, and donot know how to build a wxPython script within c. here is the error message: Detected memory leaks! Dumping objects -> {6417} normal block at 0x01B72B30, 262144 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {6339} normal block at 0x01B0A9C8, 480 bytes long. Data: < @_ > 00 00 01 D0 FB FB FB FB 40 5F AD 01 20 92 AD 01 {6338} normal block at 0x01B0A7D0, 440 bytes long. ..... {48} normal block at 0x003F2C88, 64 bytes long. Data: 68 00 A4 00 08 20 A9 00 68 00 B4 00 B8 11 B8 00 {47} normal block at 0x00A40068, 262144 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {45} normal block at 0x003F4F10, 12 bytes long. Data: < > FF FF FF FF 00 00 00 00 C0 07 00 00 Object dump complete. The thread 'Win32 Thread' (0x9ec) has exited with code 0 (0x0). The program '[2960] wxPythonGUI.exe: Native' has exited with code 0 (0x0). thanks one billion times if someone can tell me,coz the progress should be advanced further.and all my other people awaits it. regards, jolley.d.tan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601607&group_id=5470 From noreply at sourceforge.net Thu Nov 23 10:39:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Nov 2006 01:39:57 -0800 Subject: [ python-Bugs-1601630 ] getopt Documentation improvement Message-ID: Bugs item #1601630, was opened at 2006-11-23 09: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=1601630&group_id=5470 Please note that this 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 Private: No Submitted By: Thomas Guettler (guettli) Assigned to: Nobody/Anonymous (nobody) Summary: getopt Documentation improvement Initial Comment: Hi, I think the documentation of getopt could be improved The example at the buttom: http://docs.python.org/lib/module-getopt.html 1. Print str(exc) except getopt.GetoptError, exc: print str(exc) usage() 2. In the loop: use elif and else for o, a in opts: if o == "-v": verbose = True elif o in ("-h", "--help"): usage() sys.exit() else: raise AssertionError( "Unparsed Paremter: %s %s" %(o, a)) 3. I would support --verbose, too ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601630&group_id=5470 From noreply at sourceforge.net Thu Nov 23 10:55:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Nov 2006 01:55:41 -0800 Subject: [ python-Bugs-1601630 ] getopt Documentation improvement Message-ID: Bugs item #1601630, was opened at 2006-11-23 09:39 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601630&group_id=5470 Please note that this 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 Private: No Submitted By: Thomas Guettler (guettli) >Assigned to: Georg Brandl (gbrandl) Summary: getopt Documentation improvement Initial Comment: Hi, I think the documentation of getopt could be improved The example at the buttom: http://docs.python.org/lib/module-getopt.html 1. Print str(exc) except getopt.GetoptError, exc: print str(exc) usage() 2. In the loop: use elif and else for o, a in opts: if o == "-v": verbose = True elif o in ("-h", "--help"): usage() sys.exit() else: raise AssertionError( "Unparsed Paremter: %s %s" %(o, a)) 3. I would support --verbose, too ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-23 09:55 Message: Logged In: YES user_id=849994 Originator: NO Thanks, committed something along your lines in rev. 52833, 52834 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601630&group_id=5470 From noreply at sourceforge.net Thu Nov 23 18:52:01 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Nov 2006 09:52:01 -0800 Subject: [ python-Bugs-1579029 ] --disable-sunaudiodev --disable-tk does not work Message-ID: Bugs item #1579029, was opened at 2006-10-17 17:03 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.5 Status: Open Resolution: Wont Fix Priority: 5 Private: No Submitted By: ThurnerRupert (thurnerrupert) Assigned to: Martin v. L?wis (loewis) Summary: --disable-sunaudiodev --disable-tk does not work Initial Comment: trying to disable sunaudiodev and tk does not really work in solaris. ./configure --prefix=/usr/local/Python-2.5 --enable- shared --disable-sunaudiodev --disable-tk building 'sunaudiodev' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/sunaudiodev.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/sunaudiodev.o /usr/local/Python-2.5/Modules/sunaudiodev.c:20:25: sun/audioio.h: No such file or directory building '_tkinter' extension gcc -fPIC -fno-strict-aliasing -DNDEBUG -g -O3 -Wall - Wstrict-prototypes -DWITH_APPINIT=1 - I/usr/openwin/include -I. -I/usr/local/Python- 2.5/./Include -I/cs/ecms/2.0.0/include -I./Include - I. -I/usr/local/include -I/usr/local/Python- 2.5/Include -I/usr/local/Python-2.5 - c /usr/local/Python-2.5/Modules/_tkinter.c -o build/temp.solaris-2.8-sun4u-2.5/usr/local/Python- 2.5/Modules/_tkinter.o In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:96:23: X11/Xlib.h: No such file or directory In file included from /usr/local/Python- 2.5/Modules/_tkinter.c:67: /usr/local/include/tk.h:572: error: syntax error before "Window" /usr/local/include/tk.h:572: error: `Window' declared as function returning a function /usr/local/include/tk.h:575: error: syntax error before "XEvent" /usr/local/include/tk.h:584: error: syntax error before "Tk_ClassCreateProc" /usr/local/include/tk.h:592: error: syntax error before '}' token /usr/local/include/tk.h:678: error: syntax error before "Bool" is it possible to correct this or state clearly in the configure options how to disable it correctly? we also checked the Modules/Setup and both seems commented. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-23 18:52 Message: Logged In: YES user_id=21627 Originator: NO It's not sun/audioio.h that's missing, but (apparently) /usr/include/sys/audioio.h; this should have come from the SUNWaudh package (Audio Header Files). If you want to find out what works and what not, you should run the test suite. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-23 09:20 Message: Logged In: YES user_id=1597584 Originator: YES which header files do you mean? the sun/audioio.h header file e.g. is not there, but standard sun header files of course are there. it is though possible to get a running python. but i'm unsure what works and what not, so you could classify it as "cleanup" too, if you prefer. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-22 22:53 Message: Logged In: YES user_id=21627 Originator: NO You still haven't demonstrated a problem. Compiling Python produces some error messages, sure, but does the resulting Python binary actually work or not? If it works, what is the problem? That you appreciate not to see error messages does not make it a bug. You cannot build Python *at all* with just the standard gnu from sunfreeware.com. You do need system header files, and those are not provided by GCC. So if you have header files, where did you get them from? ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-22 12:50 Message: Logged In: YES user_id=1597584 Originator: YES may i open it again? there is a lot of builds on solaris without the core development environment, so assuming it is there is erronous. e.g. we build everything with standard gnu from e.g. sunfreeware.com. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-19 09:15 Message: Logged In: YES user_id=21627 Originator: NO Closing as "won't fix". There are no plans to implement --disable-sunaudiodev --disable-tk options to configure. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-06 18:51 Message: Logged In: YES user_id=21627 The component isn't vital. It shouldn't be relevant for building sunaudiodev whether an audio device is present in the system, as this device isn't necessary for *building* Python. Instead, presence of /usr/include/sys/audioio.h is necessary. I'm puzzled that this file isn't there (it is part of the core development environment, AFAIK); the build process assumes that the header is present if the system name is "sunos5". ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-06 10:23 Message: Logged In: YES user_id=1597584 i would appreciate if the build completes without errors. i won't care if it attemts to build, but it should figure out that the sunaudiodev is not there. to my knowledge servers do not need that component. and python should not need it too then. do you see any reason why these components are vital for python? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-04 00:25 Message: Logged In: YES user_id=21627 It doesn't build the modules, as it doesn't succeed when attempting to. Why do you want it not to attempt? ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-03 12:56 Message: Logged In: YES user_id=1597584 what do you suggest then to convince the build not to build it? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-02 06:40 Message: Logged In: YES user_id=21627 Re: enable/disable: What makes you think "sunaudiodev" and "tk" are valid values for "FEATURE"? configure --help lists the valid values for FEATURE, namely universalsdk, framework, shared, profiling, toolbox-glue, ipv6, and unicode. Re: there is a compilation error. Sure, an error is reported. However, compilation should not fail because of that. Instead, compilation should complete successfully, and just end up not building these modules. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-02 00:31 Message: Logged In: YES user_id=1597584 and there is no X on the server. ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:49 Message: Logged In: YES user_id=1597584 and what does that mean? Optional Features: --disable-FEATURE do not include FEATURE (same as --enable-FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] ---------------------------------------------------------------------- Comment By: ThurnerRupert (thurnerrupert) Date: 2006-11-01 23:47 Message: Logged In: YES user_id=1597584 because there is a compilation error with both. sunaudio.h seems not to exist on our server, and tk gives other compilation errors. and i have no idea why i would need these modules on our server. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-17 17:43 Message: Logged In: YES user_id=21627 I fail to see a bug here. What makes you think --disable-sunaudiodev --disable-tk exist? ./configure --help does not claim they do. In fact, it is not possible to disable modules. Why do you want that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579029&group_id=5470 From noreply at sourceforge.net Thu Nov 23 19:02:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Nov 2006 10:02:10 -0800 Subject: [ python-Bugs-1601607 ] using python extension(wxPython) in c Message-ID: Bugs item #1601607, was opened at 2006-11-23 09:52 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601607&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: jolleydtan (jolleydtan) Assigned to: Nobody/Anonymous (nobody) Summary: using python extension(wxPython) in c Initial Comment: hello,all. i am confronting with a weird problem, almost forcing to die,the feeling is miserable, so pls help me. here is a python application named "helloWorld",a simple gui application, assisted with wxPython. from wxPython.wx import * class myApp(wxApp): def OnInit(self): frame = wxFrame(NULL,-1,"hello,world!"); frame.Show(true) self.SetTopWindow(frame) return true app = myApp() app.MainLoop() also sorry for my unsmart code, which i should import wx not wxPython.wx. and i want to use the simplest way to combine with c.so i use: #include "python.h" #include "wx/wxPython/wxPython.h" #include using namespace std; int main() { Py_Initialize(); if(!Py_IsInitialized()) { cerr << "hello,world!"<< endl; return -1; } PyRun_SimpleString("from wxPython.wx import *"); PyRun_SimpleString("class myApp(wxApp):"); PyRun_SimpleString(" def OnInit(self):"); PyRun_SimpleString(" frame = wxFrame(NULL,-1,"hello,world!")"); PyRun_SimpleString(" frame.Show(true)"); PyRun_SimpleString(" self.SetTopWindow(frame)"); PyRun_SimpleString(" return true"); PyRun_SimpleString("app = myApp()"); PyRun_SimpleString("app.MainLoop()"); Py_Finalize(); return 0; } in addition, to make this work, i have configure something like this: add the wxpython include/library files in vc. includes: c:\wxPython-src-2.6.3.3\wxPython\include. c:\python24\include\wx(it is the product of building wxPython) also the python include here. c:\python24\include libraries: c:\wxPython-src-2.6.3.3\lib\vc_dll(the build product of wxWidgets) c:\wxPython-src-2.6.3.3\wxPython\wxPython c:\python24\libs to supplement the problem, i install wxPython from source code,and i have gotten three files,all of which will be uploaded here. and both them can pass the build process,but get "detected memory leaks and dump objects"in the run process. i figure that it has great memory leaks when loading certain symbols,like wxmsw26ud.lib or such,while other lib are not loaded "no symbol loaded!" but i donot know why, and donot know how to build a wxPython script within c. here is the error message: Detected memory leaks! Dumping objects -> {6417} normal block at 0x01B72B30, 262144 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {6339} normal block at 0x01B0A9C8, 480 bytes long. Data: < @_ > 00 00 01 D0 FB FB FB FB 40 5F AD 01 20 92 AD 01 {6338} normal block at 0x01B0A7D0, 440 bytes long. ..... {48} normal block at 0x003F2C88, 64 bytes long. Data: 68 00 A4 00 08 20 A9 00 68 00 B4 00 B8 11 B8 00 {47} normal block at 0x00A40068, 262144 bytes long. Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD {45} normal block at 0x003F4F10, 12 bytes long. Data: < > FF FF FF FF 00 00 00 00 C0 07 00 00 Object dump complete. The thread 'Win32 Thread' (0x9ec) has exited with code 0 (0x0). The program '[2960] wxPythonGUI.exe: Native' has exited with code 0 (0x0). thanks one billion times if someone can tell me,coz the progress should be advanced further.and all my other people awaits it. regards, jolley.d.tan ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-23 19:02 Message: Logged In: YES user_id=21627 Originator: NO Please don't use the bug tracker as a means to get support; it is not meant to be used that way. Instead, try to get help e.g. on news:comp.lang.python I can see various errors in your code; as a starting point, check the result of PyRun_SimpleString. Closing the report as invalid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1601607&group_id=5470 From noreply at sourceforge.net Thu Nov 23 21:47:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 23 Nov 2006 12:47:58 -0800 Subject: [ python-Bugs-1600860 ] --enable-shared links extensions to libpython statically Message-ID: Bugs item #1600860, was opened at 2006-11-22 00:29 Message generated for change (Comment added) made by gustavo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600860&group_id=5470 Please note that this 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 Private: No Submitted By: Marien Zwart (marienz) Assigned to: Nobody/Anonymous (nobody) Summary: --enable-shared links extensions to libpython statically Initial Comment: python 2.5 tries to link extension modules to libpython2.5 if python is compiled with --enable-shared (patch #1429775, bug #83279, svn r45232). To do this it adds -lpython2.5 and -L$PREFIX/lib/python2.5/config to the link command line. -lpython2.5 is fine, however the "config" directory it adds contains a static libpython2.5.a library. The libpython2.5.so I think it should be linking to is in $PREFIX/lib. The result is even a trivial extension pulls in (nearly) all of that library, so you get an extension that is over a megabyte in size where older pythons produce one of a few kilobytes. There is a comment on the referenced bug saying """ You can probably rely on libpythonxy.so ending up in $(DESTDIR)$(LIBDIR)/$(INSTSONAME), whose values you can retrieve from the installed Makefile (i.e. through distutils.config). """ so I think the patch that got applied does not do what was intended. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-11-23 20:47 Message: Logged In: YES user_id=908 Originator: NO Hmm.. I think I wrongfully assumed $prefix/lib/pythonX.Y/config contained a shared python library in addition to the static one. It seems that was an Ubuntu specific thing :| I'll take a good look and fix this within a couple of days... ---------------------------------------------------------------------- Comment By: Marien Zwart (marienz) Date: 2006-11-22 13:02 Message: Logged In: YES user_id=857292 Originator: YES I can reproduce this by using either gentoo's python 2.5 or one I installed temporarily with ./configure --enable-shared --prefix $HOME/tmp/pytem, using a trivial distutils extension (I used http://dev.gentooexperimental.org/~marienz/ext.c and http://dev.gentooexperimental.org/~marienz/setup.py for testing). The relevant command that is run is: gcc -pthread -shared build/temp.linux-i686-2.5/ext.o -L/home/marienz/tmp/pytem/lib/python2.5/config -lpython2.5 -o build/lib.linux-i686-2.5/ext.so for the manually-configured python and something similar for gentoo's python. The code doing the adding was added by r45232 in svn. From the diff (svn di -r45231:45232 http://svn.python.org/projects/python/trunk/Lib/distutils/command/build_ext.py) with some extra context added: - if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos': + if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos' or \ + (sys.platform.startswith('linux') and + sysconfig.get_config_var('Py_ENABLE_SHARED')): if string.find(sys.executable, sys.exec_prefix) != -1: # building third party extensions self.library_dirs.append(os.path.join(sys.prefix, "lib", "python" + get_python_version(), "config")) (that is around line 188 of Lib/distutils/command/build_ext.py) sys.platform on this host is linux2 and as far as I can tell Py_ENABLE_SHARED is true if --enable-shared is passed to configure. If you need any more information please ask. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-22 07:09 Message: Logged In: YES user_id=21627 Originator: NO I can't reproduce the problem. Why do you think -L$PREFIX/lib/python2.5/config is added to the link command line? AFAICT, it never is. What operating system are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600860&group_id=5470 From noreply at sourceforge.net Fri Nov 24 11:07:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Nov 2006 02:07:23 -0800 Subject: [ python-Feature Requests-1602189 ] Suggest a textlist() method for ElementTree Message-ID: Feature Requests item #1602189, was opened at 2006-11-24 05:00 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1602189&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Hettinger (rhettinger) Assigned to: Fred L. Drake, Jr. (fdrake) Summary: Suggest a textlist() method for ElementTree Initial Comment: This patch has a implementation and example for a method to recursively extract prose from nested XML markup. This improves the utility of ElementTree for documents where otherwise contiguous PCDATA are broken-up by inspersed tags (e.g. xhtml or docbook fragments). See attached file or the ASPN recipe at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/498286 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1602189&group_id=5470 From noreply at sourceforge.net Fri Nov 24 18:07:28 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Nov 2006 09:07:28 -0800 Subject: [ python-Bugs-1602378 ] Incorrect docs for bisect_left Message-ID: Bugs item #1602378, was opened at 2006-11-24 09: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=1602378&group_id=5470 Please note that this 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 Private: No Submitted By: Daniel Eloff (eloff) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect docs for bisect_left Initial Comment: Quote: Return the index where to insert item x in list a, assuming a is sorted. The return value i is such that all e in a[:i] have e < x, and all e in a[i:] have e >= x. So if x already appears in the list, i points just before the leftmost x already there. The last sentence is incorrect, and it contradicts what comes earlier. Not knowing which is correct, I had to test it in the shell. >>> from bisect import * >>> l = [1,2,3,3,3,4,5] >>> bisect_left(l,3) 2 >>> l[2:] [3, 3, 3, 4, 5] It should be changed to read "i points at the leftmost x already there" -Dan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1602378&group_id=5470 From noreply at sourceforge.net Fri Nov 24 19:19:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Nov 2006 10:19:18 -0800 Subject: [ python-Bugs-1602378 ] Incorrect docs for bisect_left Message-ID: Bugs item #1602378, was opened at 2006-11-24 12:07 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1602378&group_id=5470 Please note that this 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 Private: No Submitted By: Daniel Eloff (eloff) >Assigned to: Raymond Hettinger (rhettinger) Summary: Incorrect docs for bisect_left Initial Comment: Quote: Return the index where to insert item x in list a, assuming a is sorted. The return value i is such that all e in a[:i] have e < x, and all e in a[i:] have e >= x. So if x already appears in the list, i points just before the leftmost x already there. The last sentence is incorrect, and it contradicts what comes earlier. Not knowing which is correct, I had to test it in the shell. >>> from bisect import * >>> l = [1,2,3,3,3,4,5] >>> bisect_left(l,3) 2 >>> l[2:] [3, 3, 3, 4, 5] It should be changed to read "i points at the leftmost x already there" -Dan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1602378&group_id=5470 From noreply at sourceforge.net Fri Nov 24 20:04:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Nov 2006 11:04:58 -0800 Subject: [ python-Bugs-1598620 ] ctypes Structure allows recursive definition Message-ID: Bugs item #1598620, was opened at 2006-11-17 22:26 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598620&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Lenard Lindstrom (kermode) Assigned to: Thomas Heller (theller) Summary: ctypes Structure allows recursive definition Initial Comment: Ctypes version 1.0.1 and Python 2.4: A Partially declared structure can be used as a type in its own field declarations: Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> from ctypes import Structure, c_int, sizeof, __version__ >>> __version__ '1.0.1' >>> class S(Structure): ... pass ... >>> S._fields_ = [('i', c_int), ('s', S)] >>> sizeof(S) 4 >>> o=S(7) >>> o.s.i=12 >>> o.s.s.i=20 >>> o.i 7 >>> o.s.i 12 >>> o.s.s.i 20 >>> sizeof(o) 4 ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-11-24 20:04 Message: Logged In: YES user_id=11105 Originator: NO Fixed now in SVN, rev 52841 (trunk) and rev 52842 (release25-maint). Thanks for the report. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1598620&group_id=5470 From noreply at sourceforge.net Fri Nov 24 20:16:05 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Nov 2006 11:16:05 -0800 Subject: [ python-Bugs-1602378 ] Incorrect docs for bisect_left Message-ID: Bugs item #1602378, was opened at 2006-11-24 12: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=1602378&group_id=5470 Please note that this 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 Private: No Submitted By: Daniel Eloff (eloff) Assigned to: Raymond Hettinger (rhettinger) Summary: Incorrect docs for bisect_left Initial Comment: Quote: Return the index where to insert item x in list a, assuming a is sorted. The return value i is such that all e in a[:i] have e < x, and all e in a[i:] have e >= x. So if x already appears in the list, i points just before the leftmost x already there. The last sentence is incorrect, and it contradicts what comes earlier. Not knowing which is correct, I had to test it in the shell. >>> from bisect import * >>> l = [1,2,3,3,3,4,5] >>> bisect_left(l,3) 2 >>> l[2:] [3, 3, 3, 4, 5] It should be changed to read "i points at the leftmost x already there" -Dan ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-11-24 14:16 Message: Logged In: YES user_id=31435 Originator: NO The docs are written from the POV that indices in Python point /between/ array elements, which is the easiest way to understand slices, and that there are n+1 non-negative indices that "make obvious sense" in slices of a sequence with n elements: index 0 points "just before" element a[0], and index n "just after" element a[n-1], while for 0 < i < n-1, index i points "just before" element [i] /and/ "just after" element a[i-1]. This is also the sanest way to understand the return value of the bisect functions, which again can return n+1 values given a sequence with n elements. That said, I agree the docs are cryptic if you don't understand that first. I'm not sure this is the best place to explain it. The specific line in question could be "repaired" by saying a[i] is the leftmost x already there, identifying one of the n elements instead of one of the n+1 sequence positions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1602378&group_id=5470 From noreply at sourceforge.net Fri Nov 24 20:39:07 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 24 Nov 2006 11:39:07 -0800 Subject: [ python-Bugs-1570417 ] 2.4 & 2.5 can't create win installer on linux Message-ID: Bugs item #1570417, was opened at 2006-10-04 05:45 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570417&group_id=5470 Please note that this 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 Private: No Submitted By: Richard Jones (richard) Assigned to: Thomas Heller (theller) Summary: 2.4 & 2.5 can't create win installer on linux Initial Comment: With python 2.4.3 and 2.5 I can't build a Windows installer on Linux. I get the following error: Warning: Can't read registry to find the necessary compiler setting Make sure that Python modules _winreg, win32api or win32con are installed. removing 'build/bdist.linux-i686/wininst' (and everything under it) I can still create an installer with 2.3.5 ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-11-24 20:39 Message: Logged In: YES user_id=11105 Originator: NO Can this be closed, Martin? When I try 'setup.py bdist_wininst' on Linux, I get the warning but an exe is built. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-10-05 21:34 Message: Logged In: YES user_id=11105 For pure distributions, bdist_wininst should create installers that are independent on the Python version. This worked up to Python 2.3, starting with 2.4 problems could arise because different MS C runtime libs are used. So, to fix this problem, even for pure distributions it should be required to specify the target-version command line switch. When building on non-windows systems, or even on Windows systems for another Python version than the one used to build the installer, bdist_wininst.py could hardcode the knowledge about Python version/MSVC version for the official python.org releases. This will fail if someone builds his own version of Python, for example 2.5 with MSVC 8. The real solution would be to avoid having wininst-XXX.exe use the C runtime library at all. OTOH, in my experience using the wrong C runtime library only has small effects - the installer would fail to show output from the pre- or post-install scripts (if they are used at all). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-04 08:30 Message: Logged In: YES user_id=21627 The message you get is a warning only; you can ignore it. However, it still fails because it can't determine what msvcrt version the target python was built with. It needs to find that out because it needs to decide whether to use wininst-6.exe or wininst-7.1.exe. Thomas, can you think of a way to fix this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570417&group_id=5470 From noreply at sourceforge.net Sat Nov 25 14:10:00 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Nov 2006 05:10:00 -0800 Subject: [ python-Bugs-1600860 ] --enable-shared links extensions to libpython statically Message-ID: Bugs item #1600860, was opened at 2006-11-22 00:29 Message generated for change (Comment added) made by gustavo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600860&group_id=5470 Please note that this 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 Private: No Submitted By: Marien Zwart (marienz) Assigned to: Nobody/Anonymous (nobody) Summary: --enable-shared links extensions to libpython statically Initial Comment: python 2.5 tries to link extension modules to libpython2.5 if python is compiled with --enable-shared (patch #1429775, bug #83279, svn r45232). To do this it adds -lpython2.5 and -L$PREFIX/lib/python2.5/config to the link command line. -lpython2.5 is fine, however the "config" directory it adds contains a static libpython2.5.a library. The libpython2.5.so I think it should be linking to is in $PREFIX/lib. The result is even a trivial extension pulls in (nearly) all of that library, so you get an extension that is over a megabyte in size where older pythons produce one of a few kilobytes. There is a comment on the referenced bug saying """ You can probably rely on libpythonxy.so ending up in $(DESTDIR)$(LIBDIR)/$(INSTSONAME), whose values you can retrieve from the installed Makefile (i.e. through distutils.config). """ so I think the patch that got applied does not do what was intended. ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-11-25 13:10 Message: Logged In: YES user_id=908 Originator: NO *sigh* why doesn't SF let me attach patches? :( You can find a patch to fix this here: http://www.gnome.org/~gjc/linux-shlib.diff ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-11-23 20:47 Message: Logged In: YES user_id=908 Originator: NO Hmm.. I think I wrongfully assumed $prefix/lib/pythonX.Y/config contained a shared python library in addition to the static one. It seems that was an Ubuntu specific thing :| I'll take a good look and fix this within a couple of days... ---------------------------------------------------------------------- Comment By: Marien Zwart (marienz) Date: 2006-11-22 13:02 Message: Logged In: YES user_id=857292 Originator: YES I can reproduce this by using either gentoo's python 2.5 or one I installed temporarily with ./configure --enable-shared --prefix $HOME/tmp/pytem, using a trivial distutils extension (I used http://dev.gentooexperimental.org/~marienz/ext.c and http://dev.gentooexperimental.org/~marienz/setup.py for testing). The relevant command that is run is: gcc -pthread -shared build/temp.linux-i686-2.5/ext.o -L/home/marienz/tmp/pytem/lib/python2.5/config -lpython2.5 -o build/lib.linux-i686-2.5/ext.so for the manually-configured python and something similar for gentoo's python. The code doing the adding was added by r45232 in svn. From the diff (svn di -r45231:45232 http://svn.python.org/projects/python/trunk/Lib/distutils/command/build_ext.py) with some extra context added: - if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos': + if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos' or \ + (sys.platform.startswith('linux') and + sysconfig.get_config_var('Py_ENABLE_SHARED')): if string.find(sys.executable, sys.exec_prefix) != -1: # building third party extensions self.library_dirs.append(os.path.join(sys.prefix, "lib", "python" + get_python_version(), "config")) (that is around line 188 of Lib/distutils/command/build_ext.py) sys.platform on this host is linux2 and as far as I can tell Py_ENABLE_SHARED is true if --enable-shared is passed to configure. If you need any more information please ask. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-22 07:09 Message: Logged In: YES user_id=21627 Originator: NO I can't reproduce the problem. Why do you think -L$PREFIX/lib/python2.5/config is added to the link command line? AFAICT, it never is. What operating system are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600860&group_id=5470 From noreply at sourceforge.net Sat Nov 25 14:42:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Nov 2006 05:42:42 -0800 Subject: [ python-Bugs-1600860 ] --enable-shared links extensions to libpython statically Message-ID: Bugs item #1600860, was opened at 2006-11-22 01:29 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600860&group_id=5470 Please note that this 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 Private: No Submitted By: Marien Zwart (marienz) Assigned to: Nobody/Anonymous (nobody) Summary: --enable-shared links extensions to libpython statically Initial Comment: python 2.5 tries to link extension modules to libpython2.5 if python is compiled with --enable-shared (patch #1429775, bug #83279, svn r45232). To do this it adds -lpython2.5 and -L$PREFIX/lib/python2.5/config to the link command line. -lpython2.5 is fine, however the "config" directory it adds contains a static libpython2.5.a library. The libpython2.5.so I think it should be linking to is in $PREFIX/lib. The result is even a trivial extension pulls in (nearly) all of that library, so you get an extension that is over a megabyte in size where older pythons produce one of a few kilobytes. There is a comment on the referenced bug saying """ You can probably rely on libpythonxy.so ending up in $(DESTDIR)$(LIBDIR)/$(INSTSONAME), whose values you can retrieve from the installed Makefile (i.e. through distutils.config). """ so I think the patch that got applied does not do what was intended. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-25 14:42 Message: Logged In: YES user_id=21627 Originator: NO gustavo: you can only attach a patch if you are team member or creator of the bug report. I'm attaching your patch. marienz: can you please confirm whether this patch solves this problem? ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-11-25 14:10 Message: Logged In: YES user_id=908 Originator: NO *sigh* why doesn't SF let me attach patches? :( You can find a patch to fix this here: http://www.gnome.org/~gjc/linux-shlib.diff ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-11-23 21:47 Message: Logged In: YES user_id=908 Originator: NO Hmm.. I think I wrongfully assumed $prefix/lib/pythonX.Y/config contained a shared python library in addition to the static one. It seems that was an Ubuntu specific thing :| I'll take a good look and fix this within a couple of days... ---------------------------------------------------------------------- Comment By: Marien Zwart (marienz) Date: 2006-11-22 14:02 Message: Logged In: YES user_id=857292 Originator: YES I can reproduce this by using either gentoo's python 2.5 or one I installed temporarily with ./configure --enable-shared --prefix $HOME/tmp/pytem, using a trivial distutils extension (I used http://dev.gentooexperimental.org/~marienz/ext.c and http://dev.gentooexperimental.org/~marienz/setup.py for testing). The relevant command that is run is: gcc -pthread -shared build/temp.linux-i686-2.5/ext.o -L/home/marienz/tmp/pytem/lib/python2.5/config -lpython2.5 -o build/lib.linux-i686-2.5/ext.so for the manually-configured python and something similar for gentoo's python. The code doing the adding was added by r45232 in svn. From the diff (svn di -r45231:45232 http://svn.python.org/projects/python/trunk/Lib/distutils/command/build_ext.py) with some extra context added: - if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos': + if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos' or \ + (sys.platform.startswith('linux') and + sysconfig.get_config_var('Py_ENABLE_SHARED')): if string.find(sys.executable, sys.exec_prefix) != -1: # building third party extensions self.library_dirs.append(os.path.join(sys.prefix, "lib", "python" + get_python_version(), "config")) (that is around line 188 of Lib/distutils/command/build_ext.py) sys.platform on this host is linux2 and as far as I can tell Py_ENABLE_SHARED is true if --enable-shared is passed to configure. If you need any more information please ask. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-22 08:09 Message: Logged In: YES user_id=21627 Originator: NO I can't reproduce the problem. Why do you think -L$PREFIX/lib/python2.5/config is added to the link command line? AFAICT, it never is. What operating system are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600860&group_id=5470 From noreply at sourceforge.net Sat Nov 25 17:27:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 25 Nov 2006 08:27:13 -0800 Subject: [ python-Bugs-1602742 ] itemconfigure returns incorrect text property of text items Message-ID: Bugs item #1602742, was opened at 2006-11-25 17: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=1602742&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Wojciech Mula (wmula) Assigned to: Martin v. L?wis (loewis) Summary: itemconfigure returns incorrect text property of text items Initial Comment: Tkinter: canvas itemconfigure bug Consider following code: -- tkbug.py --- from Tkinter import * root = Tk() canvas = Canvas(root) text = "sample text with spaces" id = canvas.create_text(0, 0, text=text) text2 = canvas.itemconfigure(id)['text'][-1] print text print text2 --- eof --- This toy prints: sample text with spaces ('sample', 'text', 'with', 'spaces') The returned value is not a string -- Tk returns the same string as passed on creating item, but Tkinter split it. To fix this problem, internal method '_configure' have to be changed a bit: *** Tkinter.py.old 2006-11-20 16:48:27.000000000 +0100 --- Tkinter.py 2006-11-20 17:00:13.000000000 +0100 *************** *** 1122,1129 **** cnf = _cnfmerge(cnf) if cnf is None: cnf = {} ! for x in self.tk.split( self.tk.call(_flatten((self._w, cmd)))): cnf[x[0][1:]] = (x[0][1:],) + x[1:] return cnf if type(cnf) is StringType: --- 1122,1134 ---- cnf = _cnfmerge(cnf) if cnf is None: cnf = {} ! for x in self.tk.splitlist( self.tk.call(_flatten((self._w, cmd)))): + if type(x) is StringType: + if x.startswith('-text '): + x = self.tk.splitlist(x) + else: + x = self.tk.split(x) cnf[x[0][1:]] = (x[0][1:],) + x[1:] return cnf if type(cnf) is StringType: Maybe better/faster way is to provide Canvas method, that return a 'text' property for text items: --- def get_text(self, text_id): try: r = self.tk.call(self._w, 'itemconfigure', text_id, '-text') return self.tk.splitlist(r)[-1] except TclError: return '' --- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1602742&group_id=5470 From noreply at sourceforge.net Sun Nov 26 10:01:47 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Nov 2006 01:01:47 -0800 Subject: [ python-Bugs-1570417 ] 2.4 & 2.5 can't create win installer on linux Message-ID: Bugs item #1570417, was opened at 2006-10-04 05:45 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570417&group_id=5470 Please note that this 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: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Richard Jones (richard) Assigned to: Thomas Heller (theller) Summary: 2.4 & 2.5 can't create win installer on linux Initial Comment: With python 2.4.3 and 2.5 I can't build a Windows installer on Linux. I get the following error: Warning: Can't read registry to find the necessary compiler setting Make sure that Python modules _winreg, win32api or win32con are installed. removing 'build/bdist.linux-i686/wininst' (and everything under it) I can still create an installer with 2.3.5 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-26 10:01 Message: Logged In: YES user_id=21627 Originator: NO Ah, right. Closing this as invalid: the message is a warning, not an error. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-24 20:39 Message: Logged In: YES user_id=11105 Originator: NO Can this be closed, Martin? When I try 'setup.py bdist_wininst' on Linux, I get the warning but an exe is built. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-10-05 21:34 Message: Logged In: YES user_id=11105 For pure distributions, bdist_wininst should create installers that are independent on the Python version. This worked up to Python 2.3, starting with 2.4 problems could arise because different MS C runtime libs are used. So, to fix this problem, even for pure distributions it should be required to specify the target-version command line switch. When building on non-windows systems, or even on Windows systems for another Python version than the one used to build the installer, bdist_wininst.py could hardcode the knowledge about Python version/MSVC version for the official python.org releases. This will fail if someone builds his own version of Python, for example 2.5 with MSVC 8. The real solution would be to avoid having wininst-XXX.exe use the C runtime library at all. OTOH, in my experience using the wrong C runtime library only has small effects - the installer would fail to show output from the pre- or post-install scripts (if they are used at all). ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-04 08:30 Message: Logged In: YES user_id=21627 The message you get is a warning only; you can ignore it. However, it still fails because it can't determine what msvcrt version the target python was built with. It needs to find that out because it needs to decide whether to use wininst-6.exe or wininst-7.1.exe. Thomas, can you think of a way to fix this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1570417&group_id=5470 From noreply at sourceforge.net Sun Nov 26 14:59:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Nov 2006 05:59:37 -0800 Subject: [ python-Bugs-1603150 ] wave module forgets to close file on exception Message-ID: Bugs item #1603150, was opened at 2006-11-26 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=1603150&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: amerinese (amerinese) Assigned to: Nobody/Anonymous (nobody) Summary: wave module forgets to close file on exception Initial Comment: I am using python 2.4 on Windows XP SP2 The wave module function: f = wave.open(file) In the case that file is a path to the file and the file is not yet opened, wave.open(file) may raise an exception if the file is opened and it does not fulfill the format of a WAV file. However, it forgets to close the file when the exception is raised keeping other functions from accessing the file (at least until the file is garbage collected). The regular file opening idiom doesn't work f = wave.open(file) try: ## do something with the wav file finally: f.close() Since wave.open(file) raises an exception before return the file name, f can't be closed, but the file is open. The reason I know this is because I try to delete the file if trying to open it raises an RIFF or not a WAV file exception and it claims the file is locked. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603150&group_id=5470 From noreply at sourceforge.net Sun Nov 26 16:58:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Nov 2006 07:58:21 -0800 Subject: [ python-Bugs-1603246 ] wave module forgets to close file on exception Message-ID: Bugs item #1603246, was opened at 2006-11-26 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=1603246&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: amerinese (amerinese) Assigned to: Nobody/Anonymous (nobody) Summary: wave module forgets to close file on exception Initial Comment: I am using python 2.4 on Windows XP SP2 The wave module function: f = wave.open(file) In the case that file is a path to the file and the file is not yet opened, wave.open(file) may raise an exception if the file is opened and it does not fulfill the format of a WAV file. However, it forgets to close the file when the exception is raised keeping other functions from accessing the file (at least until the file is garbage collected). The regular file opening idiom doesn't work f = wave.open(file) try: ## do something with the wav file finally: f.close() Since wave.open(file) raises an exception before return the file name, f can't be closed, but the file is open. The reason I know this is because I try to delete the file if trying to open it raises an RIFF or not a WAV file exception and it claims the file is locked. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603246&group_id=5470 From noreply at sourceforge.net Sun Nov 26 17:01:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Nov 2006 08:01:55 -0800 Subject: [ python-Bugs-1603246 ] wave module forgets to close file on exception Message-ID: Bugs item #1603246, was opened at 2006-11-26 15:58 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603246&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: amerinese (amerinese) Assigned to: Nobody/Anonymous (nobody) Summary: wave module forgets to close file on exception Initial Comment: I am using python 2.4 on Windows XP SP2 The wave module function: f = wave.open(file) In the case that file is a path to the file and the file is not yet opened, wave.open(file) may raise an exception if the file is opened and it does not fulfill the format of a WAV file. However, it forgets to close the file when the exception is raised keeping other functions from accessing the file (at least until the file is garbage collected). The regular file opening idiom doesn't work f = wave.open(file) try: ## do something with the wav file finally: f.close() Since wave.open(file) raises an exception before return the file name, f can't be closed, but the file is open. The reason I know this is because I try to delete the file if trying to open it raises an RIFF or not a WAV file exception and it claims the file is locked. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-26 16:01 Message: Logged In: YES user_id=849994 Originator: NO Duplicate of #1603150. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603246&group_id=5470 From noreply at sourceforge.net Sun Nov 26 20:26:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Nov 2006 11:26:23 -0800 Subject: [ python-Bugs-1603321 ] pstats module (profiler) doens't support unicode paths Message-ID: Bugs item #1603321, was opened at 2006-11-26 21: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=1603321&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: pstats module (profiler) doens't support unicode paths Initial Comment: This call fails if fileName is an unicode string. stats = pstats.Stats(fileName) The cause is this line from pstats.py (line 119): ....elif type(arg) == type(""): This replacement fixes the problem: ....elif isinstance(arg, (str, unicode)): ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603321&group_id=5470 From noreply at sourceforge.net Sun Nov 26 20:28:41 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Nov 2006 11:28:41 -0800 Subject: [ python-Bugs-1603321 ] pstats module (profiler) doens't support unicode paths Message-ID: Bugs item #1603321, was opened at 2006-11-26 19:26 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603321&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Adal Chiriliuc (adalx) >Assigned to: Georg Brandl (gbrandl) Summary: pstats module (profiler) doens't support unicode paths Initial Comment: This call fails if fileName is an unicode string. stats = pstats.Stats(fileName) The cause is this line from pstats.py (line 119): ....elif type(arg) == type(""): This replacement fixes the problem: ....elif isinstance(arg, (str, unicode)): ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-26 19:28 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the report, fixed in rev. 52845, 52846 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603321&group_id=5470 From noreply at sourceforge.net Sun Nov 26 20:52:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Nov 2006 11:52:37 -0800 Subject: [ python-Bugs-1603332 ] def foo(((x))) segfault Message-ID: Bugs item #1603332, was opened at 2006-11-26 19: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=1603332&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tony Lownds (tonylownds) Assigned to: Nobody/Anonymous (nobody) Summary: def foo(((x))) segfault Initial Comment: python Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> def f(((x))): pass ... Bus error ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603332&group_id=5470 From noreply at sourceforge.net Sun Nov 26 21:01:20 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Nov 2006 12:01:20 -0800 Subject: [ python-Bugs-1603332 ] def foo(((x))) segfault Message-ID: Bugs item #1603332, was opened at 2006-11-26 19:52 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603332&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Tony Lownds (tonylownds) Assigned to: Nobody/Anonymous (nobody) Summary: def foo(((x))) segfault Initial Comment: python Python 2.5 (r25:51918, Sep 19 2006, 08:49:13) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> def f(((x))): pass ... Bus error ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-26 20:01 Message: Logged In: YES user_id=849994 Originator: NO This has already been fixed on the Subversion trunk, but thanks for the report anyway. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603332&group_id=5470 From noreply at sourceforge.net Sun Nov 26 21:08:48 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Nov 2006 12:08:48 -0800 Subject: [ python-Bugs-1603336 ] f=open fails with TypeError Message-ID: Bugs item #1603336, was opened at 2006-11-26 20: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=1603336&group_id=5470 Please note that this message 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 Private: No Submitted By: Gibholio (gibholio) Assigned to: Nobody/Anonymous (nobody) Summary: f=open fails with TypeError Initial Comment: I've found that Python 2.5 halts, giving a TypeError, when opening a file to write to. This is the error (path is shortened for compactness): Traceback (most recent call last): File "C:\...\BatchGen.py", line 32, in f=open('ImGen.bat', 'w') TypeError: an integer is required I noticed that calling an external command via os.system() would always make the error occur, but now it is happening all the time. I've tried this on two machines, both running Windows XP SP2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603336&group_id=5470 From noreply at sourceforge.net Sun Nov 26 21:47:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Nov 2006 12:47:40 -0800 Subject: [ python-Bugs-1603336 ] f=open fails with TypeError Message-ID: Bugs item #1603336, was opened at 2006-11-26 20:08 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603336&group_id=5470 Please note that this message 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: Pending >Resolution: Works For Me Priority: 5 Private: No Submitted By: Gibholio (gibholio) Assigned to: Nobody/Anonymous (nobody) Summary: f=open fails with TypeError Initial Comment: I've found that Python 2.5 halts, giving a TypeError, when opening a file to write to. This is the error (path is shortened for compactness): Traceback (most recent call last): File "C:\...\BatchGen.py", line 32, in f=open('ImGen.bat', 'w') TypeError: an integer is required I noticed that calling an external command via os.system() would always make the error occur, but now it is happening all the time. I've tried this on two machines, both running Windows XP SP2. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-26 20:47 Message: Logged In: YES user_id=849994 Originator: NO This looks a bit fishy to me. Are you sure that "open" isn't bound to something else in your script? (Try replacing it with "file" for a start) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603336&group_id=5470 From noreply at sourceforge.net Mon Nov 27 00:44:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Nov 2006 15:44:06 -0800 Subject: [ python-Bugs-1603412 ] f=open fails with TypeError Message-ID: Bugs item #1603412, was opened at 2006-11-26 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=1603412&group_id=5470 Please note that this message 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 Private: No Submitted By: Gibholio (gibholio) Assigned to: Nobody/Anonymous (nobody) Summary: f=open fails with TypeError Initial Comment: I've found that Python 2.5 halts, giving a TypeError, when opening a file to write to. This is the error (path is shortened for compactness): Traceback (most recent call last): File "C:\...\BatchGen.py", line 32, in f=open('ImGen.bat', 'w') TypeError: an integer is required I noticed that calling an external command via os.system() would always make the error occur, but now it is happening all the time. I've tried this on two machines, both running Windows XP SP2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603412&group_id=5470 From noreply at sourceforge.net Mon Nov 27 02:01:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Nov 2006 17:01:52 -0800 Subject: [ python-Bugs-1600860 ] --enable-shared links extensions to libpython statically Message-ID: Bugs item #1600860, was opened at 2006-11-22 01:29 Message generated for change (Comment added) made by marienz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600860&group_id=5470 Please note that this 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 Private: No Submitted By: Marien Zwart (marienz) Assigned to: Nobody/Anonymous (nobody) Summary: --enable-shared links extensions to libpython statically Initial Comment: python 2.5 tries to link extension modules to libpython2.5 if python is compiled with --enable-shared (patch #1429775, bug #83279, svn r45232). To do this it adds -lpython2.5 and -L$PREFIX/lib/python2.5/config to the link command line. -lpython2.5 is fine, however the "config" directory it adds contains a static libpython2.5.a library. The libpython2.5.so I think it should be linking to is in $PREFIX/lib. The result is even a trivial extension pulls in (nearly) all of that library, so you get an extension that is over a megabyte in size where older pythons produce one of a few kilobytes. There is a comment on the referenced bug saying """ You can probably rely on libpythonxy.so ending up in $(DESTDIR)$(LIBDIR)/$(INSTSONAME), whose values you can retrieve from the installed Makefile (i.e. through distutils.config). """ so I think the patch that got applied does not do what was intended. ---------------------------------------------------------------------- >Comment By: Marien Zwart (marienz) Date: 2006-11-27 02:01 Message: Logged In: YES user_id=857292 Originator: YES Yes, that seems to fix it, thanks! ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-25 14:42 Message: Logged In: YES user_id=21627 Originator: NO gustavo: you can only attach a patch if you are team member or creator of the bug report. I'm attaching your patch. marienz: can you please confirm whether this patch solves this problem? ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-11-25 14:10 Message: Logged In: YES user_id=908 Originator: NO *sigh* why doesn't SF let me attach patches? :( You can find a patch to fix this here: http://www.gnome.org/~gjc/linux-shlib.diff ---------------------------------------------------------------------- Comment By: Gustavo J. A. M. Carneiro (gustavo) Date: 2006-11-23 21:47 Message: Logged In: YES user_id=908 Originator: NO Hmm.. I think I wrongfully assumed $prefix/lib/pythonX.Y/config contained a shared python library in addition to the static one. It seems that was an Ubuntu specific thing :| I'll take a good look and fix this within a couple of days... ---------------------------------------------------------------------- Comment By: Marien Zwart (marienz) Date: 2006-11-22 14:02 Message: Logged In: YES user_id=857292 Originator: YES I can reproduce this by using either gentoo's python 2.5 or one I installed temporarily with ./configure --enable-shared --prefix $HOME/tmp/pytem, using a trivial distutils extension (I used http://dev.gentooexperimental.org/~marienz/ext.c and http://dev.gentooexperimental.org/~marienz/setup.py for testing). The relevant command that is run is: gcc -pthread -shared build/temp.linux-i686-2.5/ext.o -L/home/marienz/tmp/pytem/lib/python2.5/config -lpython2.5 -o build/lib.linux-i686-2.5/ext.so for the manually-configured python and something similar for gentoo's python. The code doing the adding was added by r45232 in svn. From the diff (svn di -r45231:45232 http://svn.python.org/projects/python/trunk/Lib/distutils/command/build_ext.py) with some extra context added: - if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos': + if sys.platform[:6] == 'cygwin' or sys.platform[:6] == 'atheos' or \ + (sys.platform.startswith('linux') and + sysconfig.get_config_var('Py_ENABLE_SHARED')): if string.find(sys.executable, sys.exec_prefix) != -1: # building third party extensions self.library_dirs.append(os.path.join(sys.prefix, "lib", "python" + get_python_version(), "config")) (that is around line 188 of Lib/distutils/command/build_ext.py) sys.platform on this host is linux2 and as far as I can tell Py_ENABLE_SHARED is true if --enable-shared is passed to configure. If you need any more information please ask. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-22 08:09 Message: Logged In: YES user_id=21627 Originator: NO I can't reproduce the problem. Why do you think -L$PREFIX/lib/python2.5/config is added to the link command line? AFAICT, it never is. What operating system are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1600860&group_id=5470 From noreply at sourceforge.net Mon Nov 27 02:07:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Nov 2006 17:07:17 -0800 Subject: [ python-Bugs-1603424 ] subprocess.py (py2.5) wrongly claims py2.2 compatibility Message-ID: Bugs item #1603424, was opened at 2006-11-27 11:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603424&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Tim Wegener (twegener) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.py (py2.5) wrongly claims py2.2 compatibility Initial Comment: >From the comments in subprocess.py (py2.5): # This module should remain compatible with Python 2.2, see PEP 291. However, using it from Python 2.2 gives: NameError: global name 'set' is not defined (set built-in used on line 1005) The subprocess.py in py2.4 was 2.2 compatible. Either the compatibility comment should be removed/amended or compatibility fixed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603424&group_id=5470 From noreply at sourceforge.net Mon Nov 27 06:28:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Nov 2006 21:28:12 -0800 Subject: [ python-Bugs-1603412 ] f=open fails with TypeError Message-ID: Bugs item #1603412, was opened at 2006-11-26 15:44 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603412&group_id=5470 Please note that this message 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 Private: No Submitted By: Gibholio (gibholio) >Assigned to: Neal Norwitz (nnorwitz) Summary: f=open fails with TypeError Initial Comment: I've found that Python 2.5 halts, giving a TypeError, when opening a file to write to. This is the error (path is shortened for compactness): Traceback (most recent call last): File "C:\...\BatchGen.py", line 32, in f=open('ImGen.bat', 'w') TypeError: an integer is required I noticed that calling an external command via os.system() would always make the error occur, but now it is happening all the time. I've tried this on two machines, both running Windows XP SP2. ---------------------------------------------------------------------- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-11-26 21:28 Message: Logged In: YES user_id=33168 Originator: NO This isn't a bug. The problem is that you are doing: from os import * which shadows the builtin open. os.open() has a different signature. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603412&group_id=5470 From noreply at sourceforge.net Mon Nov 27 06:43:40 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Nov 2006 21:43:40 -0800 Subject: [ python-Bugs-1603527 ] Python socket library confused by IPV6 notation in /etc/host Message-ID: Bugs item #1603527, was opened at 2006-11-27 05:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Eric S. Raymond (esr) Assigned to: Nobody/Anonymous (nobody) Summary: Python socket library confused by IPV6 notation in /etc/host Initial Comment: Robert J.Berger reported this on the gpsd-dev mailing list of the GPSD project. "Until I changed the line in /etc/hosts from: ::1 localhost.localdomain localhost to: 127.0.0.1 localhost.localdomain localhost the gps.py [library distributed by the GPSD project] would fail when trying to open the socket connection to gpsd: File "/usr/local/bin/spGps.py", line 198, in __init__ self.connect(host, port) File "/usr/local/bin/spGps.py", line 237, in connect raise socket.error, msg socket.error: (111, 'Connection refused') This is with Python 2.4.4 under Red Hat Linux, kernel version not reported. Robert believes, and I concur, that this is not a GPSD bug. Rather, something lower-level -- possibly the Python socket library, possibly some C library it uses -- is having indigestion on the IPV6 notation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&group_id=5470 From noreply at sourceforge.net Mon Nov 27 07:03:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Nov 2006 22:03:34 -0800 Subject: [ python-Bugs-1603527 ] Python socket library confused by IPV6 notation in /etc/host Message-ID: Bugs item #1603527, was opened at 2006-11-27 05:43 Message generated for change (Comment added) made by esr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Eric S. Raymond (esr) Assigned to: Nobody/Anonymous (nobody) Summary: Python socket library confused by IPV6 notation in /etc/host Initial Comment: Robert J.Berger reported this on the gpsd-dev mailing list of the GPSD project. "Until I changed the line in /etc/hosts from: ::1 localhost.localdomain localhost to: 127.0.0.1 localhost.localdomain localhost the gps.py [library distributed by the GPSD project] would fail when trying to open the socket connection to gpsd: File "/usr/local/bin/spGps.py", line 198, in __init__ self.connect(host, port) File "/usr/local/bin/spGps.py", line 237, in connect raise socket.error, msg socket.error: (111, 'Connection refused') This is with Python 2.4.4 under Red Hat Linux, kernel version not reported. Robert believes, and I concur, that this is not a GPSD bug. Rather, something lower-level -- possibly the Python socket library, possibly some C library it uses -- is having indigestion on the IPV6 notation. ---------------------------------------------------------------------- >Comment By: Eric S. Raymond (esr) Date: 2006-11-27 06:03 Message: Logged In: YES user_id=3060 Originator: YES Berger reports the kernel is 2.6.18. Fedora Core 6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&group_id=5470 From noreply at sourceforge.net Mon Nov 27 08:31:56 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Nov 2006 23:31:56 -0800 Subject: [ python-Bugs-1603336 ] f=open fails with TypeError Message-ID: Bugs item #1603336, was opened at 2006-11-26 20:08 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603336&group_id=5470 Please note that this message 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 Private: No Submitted By: Gibholio (gibholio) Assigned to: Nobody/Anonymous (nobody) Summary: f=open fails with TypeError Initial Comment: I've found that Python 2.5 halts, giving a TypeError, when opening a file to write to. This is the error (path is shortened for compactness): Traceback (most recent call last): File "C:\...\BatchGen.py", line 32, in f=open('ImGen.bat', 'w') TypeError: an integer is required I noticed that calling an external command via os.system() would always make the error occur, but now it is happening all the time. I've tried this on two machines, both running Windows XP SP2. ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-27 07:31 Message: Logged In: YES user_id=849994 Originator: NO Sorry, didn't see the attached file. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-26 20:47 Message: Logged In: YES user_id=849994 Originator: NO This looks a bit fishy to me. Are you sure that "open" isn't bound to something else in your script? (Try replacing it with "file" for a start) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603336&group_id=5470 From noreply at sourceforge.net Mon Nov 27 13:15:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Nov 2006 04:15:17 -0800 Subject: [ python-Bugs-1603688 ] SaveConfigParser.write() doesn't quote %-Sign Message-ID: Bugs item #1603688, was opened at 2006-11-27 13: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=1603688&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Rebecca Breu (rbreu) Assigned to: Nobody/Anonymous (nobody) Summary: SaveConfigParser.write() doesn't quote %-Sign Initial Comment: >>> parser = ConfigParser.SafeConfigParser() >>> parser.add_section("test") >>> parser.set("test", "foo", "bar%bar") >>> parser.write(open("test.config", "w")) >>> parser2 = ConfigParser.SafeConfigParser() >>> parser2.readfp(open("test.config")) >>> parser.get("test", "foo") Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/ConfigParser.py", line 525, in get return self._interpolate(section, option, value, d) File "/usr/lib/python2.4/ConfigParser.py", line 593, in _interpolate self._interpolate_some(option, L, rawval, section, vars, 1) File "/usr/lib/python2.4/ConfigParser.py", line 634, in _interpolate_some "'%%' must be followed by '%%' or '(', found: %r" % (rest,)) ConfigParser.InterpolationSyntaxError: '%' must be followed by '%' or '(', found: '%bar' Problem: SaveConfigParser saves the string "bar%bar" as is and not as "bar%%bar". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603688&group_id=5470 From noreply at sourceforge.net Mon Nov 27 16:53:23 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Nov 2006 07:53:23 -0800 Subject: [ python-Bugs-1603789 ] grammatical error in Python Library Reference::Tkinter Message-ID: Bugs item #1603789, was opened at 2006-11-27 09: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=1603789&group_id=5470 Please note that this 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 Private: No Submitted By: Gabriel M. Elder (eldergabriel) Assigned to: Nobody/Anonymous (nobody) Summary: grammatical error in Python Library Reference::Tkinter Initial Comment: It's located here: http://www.python.org/doc/current/lib/node690.html "Flags are proceeded by a `-', like Unix shell command flags, and values are put in quotes if they are more than one word." "proceeded" should be "preceded" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603789&group_id=5470 From noreply at sourceforge.net Mon Nov 27 19:06:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Nov 2006 10:06:58 -0800 Subject: [ python-Feature Requests-1592899 ] "".translate() docs should mention string.maketrans() Message-ID: Feature Requests item #1592899, was opened at 2006-11-08 15:23 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1592899&group_id=5470 Please note that this 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 Private: No Submitted By: Ori Avtalion (salty-horse) >Assigned to: Raymond Hettinger (rhettinger) Summary: "".translate() docs should mention string.maketrans() Initial Comment: The translate() documentation at http://docs.python.org/lib/string-methods.html#l2h-268 should mention the string.maketrans helper function. maketrans also mentions "regex.compile" - that should probably be "re.compile" (although it's less readable). re.compile should mention maketrans as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1592899&group_id=5470 From noreply at sourceforge.net Mon Nov 27 19:07:18 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Nov 2006 10:07:18 -0800 Subject: [ python-Bugs-1579370 ] Segfault provoked by generators and exceptions Message-ID: Bugs item #1579370, was opened at 2006-10-18 03:23 Message generated for change (Comment added) made by eric_noyau You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470 Please note that this message 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 Private: No Submitted By: Mike Klaas (mklaas) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault provoked by generators and exceptions Initial Comment: A reproducible segfault when using heavily-nested generators and exceptions. Unfortunately, I haven't yet been able to provoke this behaviour with a standalone python2.5 script. There are, however, no third-party c extensions running in the process so I'm fairly confident that it is a problem in the core. The gist of the code is a series of nested generators which leave scope when an exception is raised. This exception is caught and re-raised in an outer loop. The old exception was holding on to the frame which was keeping the generators alive, and the sequence of generator destruction and new finalization caused the segfault. ---------------------------------------------------------------------- Comment By: Eric Noyau (eric_noyau) Date: 2006-11-27 18:07 Message: Logged In: YES user_id=1388768 Originator: NO We are experiencing the same segfault in our application, reliably. Running our unit test suite just segfault everytime on both Linux and Mac OS X. Applying Martin's patch fixes the segfault, and makes everything fine and dandy, at the cost of some memory leaks if I understand properly. This particular bug prevents us to upgrade to python 2.5 in production. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-10-28 06:18 Message: Logged In: YES user_id=31435 > I tried Tim's hope.py on Linux x86_64 and > Mac OS X 10.4 with debug builds and neither > one crashed. Tim's guess looks pretty damn > good too. Neal, note that it's the /Windows/ malloc that fills freed memory with "dangerous bytes" in a debug build -- this really has nothing to do with that it's a debug build of /Python/ apart from that on Windows a debug build of Python also links in the debug version of Microsoft's malloc. The valgrind report is pointing at the same thing. Whether this leads to a crash is purely an accident of when and how the system malloc happens to reuse the freed memory. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-28 05:56 Message: Logged In: YES user_id=33168 Mike, what platform are you having the problem on? I tried Tim's hope.py on Linux x86_64 and Mac OS X 10.4 with debug builds and neither one crashed. Tim's guess looks pretty damn good too. Here's the result of valgrind: Invalid read of size 8 at 0x4CEBFE: PyTraceBack_Here (traceback.c:117) by 0x49C1F1: PyEval_EvalFrameEx (ceval.c:2515) by 0x4F615D: gen_send_ex (genobject.c:82) by 0x4F6326: gen_close (genobject.c:128) by 0x4F645E: gen_del (genobject.c:163) by 0x4F5F00: gen_dealloc (genobject.c:31) by 0x44D207: _Py_Dealloc (object.c:1928) by 0x44534E: dict_dealloc (dictobject.c:801) by 0x44D207: _Py_Dealloc (object.c:1928) by 0x4664FF: subtype_dealloc (typeobject.c:686) by 0x44D207: _Py_Dealloc (object.c:1928) by 0x42325D: instancemethod_dealloc (classobject.c:2287) Address 0x56550C0 is 88 bytes inside a block of size 152 free'd at 0x4A1A828: free (vg_replace_malloc.c:233) by 0x4C3899: tstate_delete_common (pystate.c:256) by 0x4C3926: PyThreadState_DeleteCurrent (pystate.c:282) by 0x4D4043: t_bootstrap (threadmodule.c:448) by 0x4B24C48: pthread_start_thread (in /lib/libpthread-0.10.so) The only way I can think to fix this is to keep a set of active generators in the PyThreadState and calling gen_send_ex(exc=1) for all the active generators before killing the tstate in t_bootstrap. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-10-19 08:58 Message: Logged In: YES user_id=6656 > and for some reason Python uses the system malloc directly > to obtain memory for thread states. This bit is fairly easy: they are allocated without the GIL being held, which breaks an assumption of PyMalloc. No idea about the real problem, sadly. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-10-19 01:38 Message: Logged In: YES user_id=31435 I've attached a much simplified pure-Python script (hope.py) that reproduces a problem very quickly, on Windows, in a /debug/ build of current trunk. It typically prints: exiting generator joined thread at most twice before crapping out. At the time, the `next` argument to newtracebackobject() is 0xdddddddd, and tracing back a level shows that, in PyTraceBack_Here(), frame->tstate is entirely filled with 0xdd bytes. Note that this is not a debug-build obmalloc gimmick! This is Microsoft's similar debug-build gimmick for their malloc, and for some reason Python uses the system malloc directly to obtain memory for thread states. The Microsoft debug free() fills newly-freed memory with 0xdd, which has the same meaning as the debug-build obmalloc's DEADBYTE (0xdb). So somebody is accessing a thread state here after it's been freed. Best guess is that the generator is getting "cleaned up" after the thread that created it has gone away, so the generator's frame's f_tstate is trash. Note that a PyThreadState (a frame's f_tstate) is /not/ a Python object -- it's just a raw C struct, and its lifetime isn't controlled by refcounts. ---------------------------------------------------------------------- Comment By: Mike Klaas (mklaas) Date: 2006-10-19 01:12 Message: Logged In: YES user_id=1611720 Despite Tim's reassurrance, I'm afraid that Martin's patch does infact prevent the segfault. Sounds like it also introduces a memleak. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-10-18 22:57 Message: Logged In: YES user_id=31435 > Can anybody tell why gi_frame *isn't* incref'ed when > the generator is created? As documented (in concrete.tex), PyGen_New(f) steals a reference to the frame passed to it. Its only call site (well, in the core) is in ceval.c, which returns immediately after PyGen_New takes over ownership of the frame the caller created: """ /* Create a new generator that owns the ready to run frame * and return that as the value. */ return PyGen_New(f); """ In short, that PyGen_New() doesn't incref the frame passed to it is intentional. It's possible that the intent is flawed ;-), but offhand I don't see how. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-18 22:05 Message: Logged In: YES user_id=21627 Can you please review/try attached patch? Can anybody tell why gi_frame *isn't* incref'ed when the generator is created? ---------------------------------------------------------------------- Comment By: Mike Klaas (mklaas) Date: 2006-10-18 20:47 Message: Logged In: YES user_id=1611720 I cannot yet produce an only-python script which reproduces the problem, but I can give an overview. There is a generator running in one thread, an exception being raised in another thread, and as a consequent, the generator in the first thread is garbage-collected (triggering an exception due to the new generator cleanup). The problem is extremely sensitive to timing--often the insertion/removal of print statements, or reordering the code, causes the problem to vanish, which is confounding my ability to create a simple test script. def getdocs(): def f(): while True: f() yield None # ----------------------------------------------------------------------------- class B(object): def __init__(self,): pass def doit(self): # must be an instance var to trigger segfault self.docIter = getdocs() print self.docIter # this is the generator referred-to in the traceback for i, item in enumerate(self.docIter): if i > 9: break print 'exiting generator' class A(object): """ Process entry point / main thread """ def __init__(self): while True: try: self.func() except Exception, e: print 'right after raise' def func(self): b = B() thread = threading.Thread(target=b.doit) thread.start() start_t = time.time() while True: try: if time.time() - start_t > 1: raise Exception except Exception: print 'right before raise' # SIGSEGV here. If this is changed to # 'break', no segfault occurs raise if __name__ == '__main__': A() ---------------------------------------------------------------------- Comment By: Mike Klaas (mklaas) Date: 2006-10-18 20:37 Message: Logged In: YES user_id=1611720 I've produced a simplified traceback with a single generator . Note the frame being used in the traceback (#0) is the same frame being dealloc'd (#11). The relevant call in traceback.c is: PyTraceBack_Here(PyFrameObject *frame) { PyThreadState *tstate = frame->f_tstate; PyTracebackObject *oldtb = (PyTracebackObject *) tstate->curexc_traceback; PyTracebackObject *tb = newtracebackobject(oldtb, frame); and I can verify that oldtb contains garbage: (gdb) print frame $1 = (PyFrameObject *) 0x8964d94 (gdb) print frame->f_tstate $2 = (PyThreadState *) 0x895b178 (gdb) print $2->curexc_traceback $3 = (PyObject *) 0x66 #0 0x080e4296 in PyTraceBack_Here (frame=0x8964d94) at Python/traceback.c:94 #1 0x080b9ab7 in PyEval_EvalFrameEx (f=0x8964d94, throwflag=1) at Python/ceval.c:2459 #2 0x08101a40 in gen_send_ex (gen=0xb7cca4ac, arg=0x81333e0, exc=1) at Objects/genobject.c:82 #3 0x08101c0f in gen_close (gen=0xb7cca4ac, args=0x0) at Objects/genobject.c:128 #4 0x08101cde in gen_del (self=0xb7cca4ac) at Objects/genobject.c:163 #5 0x0810195b in gen_dealloc (gen=0xb7cca4ac) at Objects/genobject.c:31 #6 0x080815b9 in dict_dealloc (mp=0xb7cc913c) at Objects/dictobject.c:801 #7 0x080927b2 in subtype_dealloc (self=0xb7cca76c) at Objects/typeobject.c:686 #8 0x0806028d in instancemethod_dealloc (im=0xb7d07f04) at Objects/classobject.c:2285 #9 0x080815b9 in dict_dealloc (mp=0xb7cc90b4) at Objects/dictobject.c:801 #10 0x080927b2 in subtype_dealloc (self=0xb7cca86c) at Objects/typeobject.c:686 #11 0x081028c5 in frame_dealloc (f=0x8964a94) at Objects/frameobject.c:416 #12 0x080e41b1 in tb_dealloc (tb=0xb7cc1fcc) at Python/traceback.c:34 #13 0x080e41c2 in tb_dealloc (tb=0xb7cc1f7c) at Python/traceback.c:33 #14 0x08080dca in insertdict (mp=0xb7f99824, key=0xb7ccd020, hash=1492466088, value=0xb7ccd054) at Objects/dictobject.c:394 #15 0x080811a4 in PyDict_SetItem (op=0xb7f99824, key=0xb7ccd020, value=0xb7ccd054) at Objects/dictobject.c:619 #16 0x08082dc6 in PyDict_SetItemString (v=0xb7f99824, key=0x8129284 "exc_traceback", item=0xb7ccd054) at Objects/dictobject.c:2103 #17 0x080e2837 in PySys_SetObject (name=0x8129284 "exc_traceback", v=0xb7ccd054) at Python/sysmodule.c:82 #18 0x080bc9e5 in PyEval_EvalFrameEx (f=0x895f934, throwflag=0) at Python/ceval.c:2954 ---Type to continue, or q to quit--- #19 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f6ade8, globals=0xb7fafa44, locals=0x0, args=0xb7cc5ff8, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2833 #20 0x08104083 in function_call (func=0xb7cc7294, arg=0xb7cc5fec, kw=0x0) at Objects/funcobject.c:517 #21 0x0805a660 in PyObject_Call (func=0xb7cc7294, arg=0xb7cc5fec, kw=0x0) at Objects/abstract.c:1860 ---------------------------------------------------------------------- Comment By: Mike Klaas (mklaas) Date: 2006-10-18 03:23 Message: Logged In: YES user_id=1611720 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208400192 (LWP 26235)] 0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at Python/traceback.c:94 94 if ((next != NULL && !PyTraceBack_Check(next)) || (gdb) bt #0 0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at Python/traceback.c:94 #1 0x080b9ab7 in PyEval_EvalFrameEx (f=0x9c2d7b4, throwflag=1) at Python/ceval.c:2459 #2 0x08101a40 in gen_send_ex (gen=0xb64f880c, arg=0x81333e0, exc=1) at Objects/genobject.c:82 #3 0x08101c0f in gen_close (gen=0xb64f880c, args=0x0) at Objects/genobject.c:128 #4 0x08101cde in gen_del (self=0xb64f880c) at Objects/genobject.c:163 #5 0x0810195b in gen_dealloc (gen=0xb64f880c) at Objects/genobject.c:31 #6 0x080b9912 in PyEval_EvalFrameEx (f=0x9c2802c, throwflag=1) at Python/ceval.c:2491 #7 0x08101a40 in gen_send_ex (gen=0xb64f362c, arg=0x81333e0, exc=1) at Objects/genobject.c:82 #8 0x08101c0f in gen_close (gen=0xb64f362c, args=0x0) at Objects/genobject.c:128 #9 0x08101cde in gen_del (self=0xb64f362c) at Objects/genobject.c:163 #10 0x0810195b in gen_dealloc (gen=0xb64f362c) at Objects/genobject.c:31 #11 0x080815b9 in dict_dealloc (mp=0xb64f4a44) at Objects/dictobject.c:801 #12 0x080927b2 in subtype_dealloc (self=0xb64f340c) at Objects/typeobject.c:686 #13 0x0806028d in instancemethod_dealloc (im=0xb796a0cc) at Objects/classobject.c:2285 #14 0x080815b9 in dict_dealloc (mp=0xb64f78ac) at Objects/dictobject.c:801 #15 0x080927b2 in subtype_dealloc (self=0xb64f810c) at Objects/typeobject.c:686 #16 0x081028c5 in frame_dealloc (f=0x9c272bc) at Objects/frameobject.c:416 #17 0x080e41b1 in tb_dealloc (tb=0xb799166c) at Python/traceback.c:34 #18 0x080e41c2 in tb_dealloc (tb=0xb4071284) at Python/traceback.c:33 #19 0x080e41c2 in tb_dealloc (tb=0xb7991824) at Python/traceback.c:33 #20 0x08080dca in insertdict (mp=0xb7f56824, key=0xb3fb9930, hash=1492466088, value=0xb3fb9914) at Objects/dictobject.c:394 #21 0x080811a4 in PyDict_SetItem (op=0xb7f56824, key=0xb3fb9930, value=0xb3fb9914) at Objects/dictobject.c:619 #22 0x08082dc6 in PyDict_SetItemString (v=0xb7f56824, key=0x8129284 "exc_traceback", item=0xb3fb9914) at Objects/dictobject.c:2103 #23 0x080e2837 in PySys_SetObject (name=0x8129284 "exc_traceback", v=0xb3fb9914) at Python/sysmodule.c:82 #24 0x080bc9e5 in PyEval_EvalFrameEx (f=0x9c10e7c, throwflag=0) at Python/ceval.c:2954 #25 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc890, globals=0xb7bbe57c, locals=0x0, args=0x9b8e2ac, argcount=1, kws=0x9b8e2b0, kwcount=0, defs=0xb7b7aed8, defcount=1, closure=0x0) at Python/ceval.c:2833 #26 0x080bd62a in PyEval_EvalFrameEx (f=0x9b8e16c, throwflag=0) at Python/ceval.c:3662 #27 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc848, globals=0xb7bbe57c, locals=0x0, args=0xb7af9d58, argcount=1, kws=0x9b7a818, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2833 #28 0x08104083 in function_call (func=0xb7b79c34, arg=0xb7af9d4c, kw=0xb7962c64) at Objects/funcobject.c:517 #29 0x0805a660 in PyObject_Call (func=0xb7b79c34, arg=0xb7af9d4c, kw=0xb7962c64) at Objects/abstract.c:1860 #30 0x080bcb4b in PyEval_EvalFrameEx (f=0x9b82c0c, throwflag=0) at Python/ceval.c:3846 #31 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7cd6608, globals=0xb7cd4934, locals=0x0, args=0x9b7765c, argcount=2, kws=0x9b77664, kwcount=0, defs=0x0, defcount=0, closure=0xb7cfe874) at Python/ceval.c:2833 #32 0x080bd62a in PyEval_EvalFrameEx (f=0x9b7751c, throwflag=0) at Python/ceval.c:3662 #33 0x080bdf70 in PyEval_EvalFrameEx (f=0x9a9646c, throwflag=0) at Python/ceval.c:3652 #34 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39728, globals=0xb7f6ca44, locals=0x0, args=0x9b7a00c, argcount=0, kws=0x9b7a00c, kwcount=0, defs=0x0, defcount=0, closure=0xb796410c) at Python/ceval.c:2833 #35 0x080bd62a in PyEval_EvalFrameEx (f=0x9b79ebc, throwflag=0) at Python/ceval.c:3662 #36 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39770, globals=0xb7f6ca44, locals=0x0, args=0x99086c0, argcount=0, kws=0x99086c0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2833 #37 0x080bd62a in PyEval_EvalFrameEx (f=0x9908584, throwflag=0) at Python/ceval.c:3662 #38 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f397b8, globals=0xb7f6ca44, locals=0xb7f6ca44, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2833 ---Type to continue, or q to quit--- #39 0x080bff32 in PyEval_EvalCode (co=0xb7f397b8, globals=0xb7f6ca44, locals=0xb7f6ca44) at Python/ceval.c:494 #40 0x080ddff1 in PyRun_FileExFlags (fp=0x98a4008, filename=0xbfffd4a3 "scoreserver.py", start=257, globals=0xb7f6ca44, locals=0xb7f6ca44, closeit=1, flags=0xbfffd298) at Python/pythonrun.c:1264 #41 0x080de321 in PyRun_SimpleFileExFlags (fp=Variable "fp" is not available. ) at Python/pythonrun.c:870 #42 0x08056ac4 in Py_Main (argc=1, argv=0xbfffd334) at Modules/main.c:496 #43 0x00a69d5f in __libc_start_main () from /lib/libc.so.6 #44 0x08056051 in _start () ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470 From noreply at sourceforge.net Mon Nov 27 19:13:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Nov 2006 10:13:50 -0800 Subject: [ python-Feature Requests-1572210 ] help(x) for keywords too Message-ID: Feature Requests item #1572210, was opened at 2006-10-06 10:06 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: help(x) for keywords too Initial Comment: At the interactive prompt, help(object) is very useful. It would be nice if it also worked on keywords. """ >>> help(object) Help on class object in module __builtin__: class object | The most base type """ vs """ >>> help(with) SyntaxError: invalid syntax """ At the moment, the workaround is to open the documentation, pick a document that doesn't seem quite right (language reference?), go to the index, and look for the keyword. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-11-27 13:13 Message: Logged In: YES user_id=80475 Originator: NO Ideally, if help() doesn't find local HTML files, it should be smart enough to look on doc.python.org. People who need help are not usually in a position to build their own help files. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-11-21 10:41 Message: Logged In: YES user_id=764593 Originator: YES 1600491 contains a doc patch, which is basically just adding Tom Heller's advice on *how* to build to the error message. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-10-06 14:25 Message: Logged In: YES user_id=11105 > Is this likely to be a windows build issue? No. pydoc cannot use the .chm file. Either you should download the HTML files yourself, or you can compile the .chm file in a windows command shell (note that the decompilation runs in the background, and has no user interface): C:\Python24\Doc>hh -decompile . Python24.chm C:\Python24\Doc>dir *.chm Datentr?ger in Laufwerk C: ist ... Volumeseriennummer: ... Verzeichnis von C:\Python24\Doc 06.10.2006 21:23 3.732 about.html 06.10.2006 21:23 8.689 acks.html 06.10.2006 21:23 4.445 index.html 06.10.2006 21:23 35.525 modindex.html 4 Datei(en) 52.391 Bytes 0 Verzeichnis(se), 8.506.798.080 Bytes frei C:\Python24\Doc> The other HTML files are created in subdirectories, and help("if") now works. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-10-06 11:26 Message: Logged In: YES user_id=764593 No, it doesn't -- but putting the keyword in quotes does at least change the error message to saying that topic and keyword documentation is not available because the Python HTML documentation files could not be found. I'm using Windows XP, the 2.4 and 2.5 binaries from python.org, if I changed anything it was just the install directory to be Python2.5 (or 2.4 for 2.4)) The documentation (as a chm file) is found by the F1 key. Is this likely to be a windows build issue? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-10-06 10:59 Message: Logged In: YES user_id=849994 Doesn't help("if") work for you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470 From noreply at sourceforge.net Mon Nov 27 19:23:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Nov 2006 10:23:57 -0800 Subject: [ python-Feature Requests-1572210 ] help(x) for keywords too Message-ID: Feature Requests item #1572210, was opened at 2006-10-06 11:06 Message generated for change (Comment added) made by jimjjewett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Jim Jewett (jimjjewett) Assigned to: Nobody/Anonymous (nobody) Summary: help(x) for keywords too Initial Comment: At the interactive prompt, help(object) is very useful. It would be nice if it also worked on keywords. """ >>> help(object) Help on class object in module __builtin__: class object | The most base type """ vs """ >>> help(with) SyntaxError: invalid syntax """ At the moment, the workaround is to open the documentation, pick a document that doesn't seem quite right (language reference?), go to the index, and look for the keyword. ---------------------------------------------------------------------- >Comment By: Jim Jewett (jimjjewett) Date: 2006-11-27 13:23 Message: Logged In: YES user_id=764593 Originator: YES Pointing to docs.python.org doesn't help if you don't have a current net connection. In this case, the build instructions *are* the single line from Thomas: C:\Python24\Doc>hh -decompile . Python25.chm Since hh comes with windows, the barrier is fairly low. ---------------------------------------------------------------------- Comment By: Raymond Hettinger (rhettinger) Date: 2006-11-27 13:13 Message: Logged In: YES user_id=80475 Originator: NO Ideally, if help() doesn't find local HTML files, it should be smart enough to look on doc.python.org. People who need help are not usually in a position to build their own help files. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-11-21 10:41 Message: Logged In: YES user_id=764593 Originator: YES 1600491 contains a doc patch, which is basically just adding Tom Heller's advice on *how* to build to the error message. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-10-06 15:25 Message: Logged In: YES user_id=11105 > Is this likely to be a windows build issue? No. pydoc cannot use the .chm file. Either you should download the HTML files yourself, or you can compile the .chm file in a windows command shell (note that the decompilation runs in the background, and has no user interface): C:\Python24\Doc>hh -decompile . Python24.chm C:\Python24\Doc>dir *.chm Datentr?ger in Laufwerk C: ist ... Volumeseriennummer: ... Verzeichnis von C:\Python24\Doc 06.10.2006 21:23 3.732 about.html 06.10.2006 21:23 8.689 acks.html 06.10.2006 21:23 4.445 index.html 06.10.2006 21:23 35.525 modindex.html 4 Datei(en) 52.391 Bytes 0 Verzeichnis(se), 8.506.798.080 Bytes frei C:\Python24\Doc> The other HTML files are created in subdirectories, and help("if") now works. ---------------------------------------------------------------------- Comment By: Jim Jewett (jimjjewett) Date: 2006-10-06 12:26 Message: Logged In: YES user_id=764593 No, it doesn't -- but putting the keyword in quotes does at least change the error message to saying that topic and keyword documentation is not available because the Python HTML documentation files could not be found. I'm using Windows XP, the 2.4 and 2.5 binaries from python.org, if I changed anything it was just the install directory to be Python2.5 (or 2.4 for 2.4)) The documentation (as a chm file) is found by the F1 key. Is this likely to be a windows build issue? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-10-06 11:59 Message: Logged In: YES user_id=849994 Doesn't help("if") work for you? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1572210&group_id=5470 From noreply at sourceforge.net Mon Nov 27 19:28:57 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Nov 2006 10:28:57 -0800 Subject: [ python-Bugs-1575169 ] isSequenceType returns True for dict subclasses (<> 2.3) Message-ID: Bugs item #1575169, was opened at 2006-10-11 05:35 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575169&group_id=5470 Please note that this message 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 Private: No Submitted By: Martin Gfeller (gfe) Assigned to: Raymond Hettinger (rhettinger) Summary: isSequenceType returns True for dict subclasses (<> 2.3) Initial Comment: The following behavior is correct according to the documentation. However, it seems weird to me, and broke my code when going from 2.3 to 2.4: Python 2.4.2: >>> import operator >>> class deriveddict(dict): pass ... >>> d =dict() >>> dd = deriveddict() >>> operator.isSequenceType(d) False >>> operator.isSequenceType(dd) True The last statement returns False in Python 2.3.4. ---------------------------------------------------------------------- >Comment By: Raymond Hettinger (rhettinger) Date: 2006-11-27 13:28 Message: Logged In: YES user_id=80475 Originator: NO Hmm, it may be possible to make the test smarter by checking base classes known mappings or known sequences in cases where the __getitem__ method hasn't been overridden. That would reduce false positives in cases like this where there is some hint as to whether the __getitem__ method is for mapping or for sequence behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1575169&group_id=5470 From noreply at sourceforge.net Mon Nov 27 19:41:29 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Nov 2006 10:41:29 -0800 Subject: [ python-Bugs-1579370 ] Segfault provoked by generators and exceptions Message-ID: Bugs item #1579370, was opened at 2006-10-17 19:23 Message generated for change (Comment added) made by mklaas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470 Please note that this message 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 Private: No Submitted By: Mike Klaas (mklaas) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault provoked by generators and exceptions Initial Comment: A reproducible segfault when using heavily-nested generators and exceptions. Unfortunately, I haven't yet been able to provoke this behaviour with a standalone python2.5 script. There are, however, no third-party c extensions running in the process so I'm fairly confident that it is a problem in the core. The gist of the code is a series of nested generators which leave scope when an exception is raised. This exception is caught and re-raised in an outer loop. The old exception was holding on to the frame which was keeping the generators alive, and the sequence of generator destruction and new finalization caused the segfault. ---------------------------------------------------------------------- >Comment By: Mike Klaas (mklaas) Date: 2006-11-27 10:41 Message: Logged In: YES user_id=1611720 Originator: YES The following patch resets the thread state of the generator when it is resumed, which prevents the segfault for me: Index: Objects/genobject.c =================================================================== --- Objects/genobject.c (revision 52849) +++ Objects/genobject.c (working copy) @@ -77,6 +77,7 @@ Py_XINCREF(tstate->frame); assert(f->f_back == NULL); f->f_back = tstate->frame; + f->f_tstate = tstate; gen->gi_running = 1; result = PyEval_EvalFrameEx(f, exc); ---------------------------------------------------------------------- Comment By: Eric Noyau (eric_noyau) Date: 2006-11-27 10:07 Message: Logged In: YES user_id=1388768 Originator: NO We are experiencing the same segfault in our application, reliably. Running our unit test suite just segfault everytime on both Linux and Mac OS X. Applying Martin's patch fixes the segfault, and makes everything fine and dandy, at the cost of some memory leaks if I understand properly. This particular bug prevents us to upgrade to python 2.5 in production. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-10-27 22:18 Message: Logged In: YES user_id=31435 > I tried Tim's hope.py on Linux x86_64 and > Mac OS X 10.4 with debug builds and neither > one crashed. Tim's guess looks pretty damn > good too. Neal, note that it's the /Windows/ malloc that fills freed memory with "dangerous bytes" in a debug build -- this really has nothing to do with that it's a debug build of /Python/ apart from that on Windows a debug build of Python also links in the debug version of Microsoft's malloc. The valgrind report is pointing at the same thing. Whether this leads to a crash is purely an accident of when and how the system malloc happens to reuse the freed memory. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-10-27 21:56 Message: Logged In: YES user_id=33168 Mike, what platform are you having the problem on? I tried Tim's hope.py on Linux x86_64 and Mac OS X 10.4 with debug builds and neither one crashed. Tim's guess looks pretty damn good too. Here's the result of valgrind: Invalid read of size 8 at 0x4CEBFE: PyTraceBack_Here (traceback.c:117) by 0x49C1F1: PyEval_EvalFrameEx (ceval.c:2515) by 0x4F615D: gen_send_ex (genobject.c:82) by 0x4F6326: gen_close (genobject.c:128) by 0x4F645E: gen_del (genobject.c:163) by 0x4F5F00: gen_dealloc (genobject.c:31) by 0x44D207: _Py_Dealloc (object.c:1928) by 0x44534E: dict_dealloc (dictobject.c:801) by 0x44D207: _Py_Dealloc (object.c:1928) by 0x4664FF: subtype_dealloc (typeobject.c:686) by 0x44D207: _Py_Dealloc (object.c:1928) by 0x42325D: instancemethod_dealloc (classobject.c:2287) Address 0x56550C0 is 88 bytes inside a block of size 152 free'd at 0x4A1A828: free (vg_replace_malloc.c:233) by 0x4C3899: tstate_delete_common (pystate.c:256) by 0x4C3926: PyThreadState_DeleteCurrent (pystate.c:282) by 0x4D4043: t_bootstrap (threadmodule.c:448) by 0x4B24C48: pthread_start_thread (in /lib/libpthread-0.10.so) The only way I can think to fix this is to keep a set of active generators in the PyThreadState and calling gen_send_ex(exc=1) for all the active generators before killing the tstate in t_bootstrap. ---------------------------------------------------------------------- Comment By: Michael Hudson (mwh) Date: 2006-10-19 00:58 Message: Logged In: YES user_id=6656 > and for some reason Python uses the system malloc directly > to obtain memory for thread states. This bit is fairly easy: they are allocated without the GIL being held, which breaks an assumption of PyMalloc. No idea about the real problem, sadly. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-10-18 17:38 Message: Logged In: YES user_id=31435 I've attached a much simplified pure-Python script (hope.py) that reproduces a problem very quickly, on Windows, in a /debug/ build of current trunk. It typically prints: exiting generator joined thread at most twice before crapping out. At the time, the `next` argument to newtracebackobject() is 0xdddddddd, and tracing back a level shows that, in PyTraceBack_Here(), frame->tstate is entirely filled with 0xdd bytes. Note that this is not a debug-build obmalloc gimmick! This is Microsoft's similar debug-build gimmick for their malloc, and for some reason Python uses the system malloc directly to obtain memory for thread states. The Microsoft debug free() fills newly-freed memory with 0xdd, which has the same meaning as the debug-build obmalloc's DEADBYTE (0xdb). So somebody is accessing a thread state here after it's been freed. Best guess is that the generator is getting "cleaned up" after the thread that created it has gone away, so the generator's frame's f_tstate is trash. Note that a PyThreadState (a frame's f_tstate) is /not/ a Python object -- it's just a raw C struct, and its lifetime isn't controlled by refcounts. ---------------------------------------------------------------------- Comment By: Mike Klaas (mklaas) Date: 2006-10-18 17:12 Message: Logged In: YES user_id=1611720 Despite Tim's reassurrance, I'm afraid that Martin's patch does infact prevent the segfault. Sounds like it also introduces a memleak. ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-10-18 14:57 Message: Logged In: YES user_id=31435 > Can anybody tell why gi_frame *isn't* incref'ed when > the generator is created? As documented (in concrete.tex), PyGen_New(f) steals a reference to the frame passed to it. Its only call site (well, in the core) is in ceval.c, which returns immediately after PyGen_New takes over ownership of the frame the caller created: """ /* Create a new generator that owns the ready to run frame * and return that as the value. */ return PyGen_New(f); """ In short, that PyGen_New() doesn't incref the frame passed to it is intentional. It's possible that the intent is flawed ;-), but offhand I don't see how. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-18 14:05 Message: Logged In: YES user_id=21627 Can you please review/try attached patch? Can anybody tell why gi_frame *isn't* incref'ed when the generator is created? ---------------------------------------------------------------------- Comment By: Mike Klaas (mklaas) Date: 2006-10-18 12:47 Message: Logged In: YES user_id=1611720 I cannot yet produce an only-python script which reproduces the problem, but I can give an overview. There is a generator running in one thread, an exception being raised in another thread, and as a consequent, the generator in the first thread is garbage-collected (triggering an exception due to the new generator cleanup). The problem is extremely sensitive to timing--often the insertion/removal of print statements, or reordering the code, causes the problem to vanish, which is confounding my ability to create a simple test script. def getdocs(): def f(): while True: f() yield None # ----------------------------------------------------------------------------- class B(object): def __init__(self,): pass def doit(self): # must be an instance var to trigger segfault self.docIter = getdocs() print self.docIter # this is the generator referred-to in the traceback for i, item in enumerate(self.docIter): if i > 9: break print 'exiting generator' class A(object): """ Process entry point / main thread """ def __init__(self): while True: try: self.func() except Exception, e: print 'right after raise' def func(self): b = B() thread = threading.Thread(target=b.doit) thread.start() start_t = time.time() while True: try: if time.time() - start_t > 1: raise Exception except Exception: print 'right before raise' # SIGSEGV here. If this is changed to # 'break', no segfault occurs raise if __name__ == '__main__': A() ---------------------------------------------------------------------- Comment By: Mike Klaas (mklaas) Date: 2006-10-18 12:37 Message: Logged In: YES user_id=1611720 I've produced a simplified traceback with a single generator . Note the frame being used in the traceback (#0) is the same frame being dealloc'd (#11). The relevant call in traceback.c is: PyTraceBack_Here(PyFrameObject *frame) { PyThreadState *tstate = frame->f_tstate; PyTracebackObject *oldtb = (PyTracebackObject *) tstate->curexc_traceback; PyTracebackObject *tb = newtracebackobject(oldtb, frame); and I can verify that oldtb contains garbage: (gdb) print frame $1 = (PyFrameObject *) 0x8964d94 (gdb) print frame->f_tstate $2 = (PyThreadState *) 0x895b178 (gdb) print $2->curexc_traceback $3 = (PyObject *) 0x66 #0 0x080e4296 in PyTraceBack_Here (frame=0x8964d94) at Python/traceback.c:94 #1 0x080b9ab7 in PyEval_EvalFrameEx (f=0x8964d94, throwflag=1) at Python/ceval.c:2459 #2 0x08101a40 in gen_send_ex (gen=0xb7cca4ac, arg=0x81333e0, exc=1) at Objects/genobject.c:82 #3 0x08101c0f in gen_close (gen=0xb7cca4ac, args=0x0) at Objects/genobject.c:128 #4 0x08101cde in gen_del (self=0xb7cca4ac) at Objects/genobject.c:163 #5 0x0810195b in gen_dealloc (gen=0xb7cca4ac) at Objects/genobject.c:31 #6 0x080815b9 in dict_dealloc (mp=0xb7cc913c) at Objects/dictobject.c:801 #7 0x080927b2 in subtype_dealloc (self=0xb7cca76c) at Objects/typeobject.c:686 #8 0x0806028d in instancemethod_dealloc (im=0xb7d07f04) at Objects/classobject.c:2285 #9 0x080815b9 in dict_dealloc (mp=0xb7cc90b4) at Objects/dictobject.c:801 #10 0x080927b2 in subtype_dealloc (self=0xb7cca86c) at Objects/typeobject.c:686 #11 0x081028c5 in frame_dealloc (f=0x8964a94) at Objects/frameobject.c:416 #12 0x080e41b1 in tb_dealloc (tb=0xb7cc1fcc) at Python/traceback.c:34 #13 0x080e41c2 in tb_dealloc (tb=0xb7cc1f7c) at Python/traceback.c:33 #14 0x08080dca in insertdict (mp=0xb7f99824, key=0xb7ccd020, hash=1492466088, value=0xb7ccd054) at Objects/dictobject.c:394 #15 0x080811a4 in PyDict_SetItem (op=0xb7f99824, key=0xb7ccd020, value=0xb7ccd054) at Objects/dictobject.c:619 #16 0x08082dc6 in PyDict_SetItemString (v=0xb7f99824, key=0x8129284 "exc_traceback", item=0xb7ccd054) at Objects/dictobject.c:2103 #17 0x080e2837 in PySys_SetObject (name=0x8129284 "exc_traceback", v=0xb7ccd054) at Python/sysmodule.c:82 #18 0x080bc9e5 in PyEval_EvalFrameEx (f=0x895f934, throwflag=0) at Python/ceval.c:2954 ---Type to continue, or q to quit--- #19 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f6ade8, globals=0xb7fafa44, locals=0x0, args=0xb7cc5ff8, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2833 #20 0x08104083 in function_call (func=0xb7cc7294, arg=0xb7cc5fec, kw=0x0) at Objects/funcobject.c:517 #21 0x0805a660 in PyObject_Call (func=0xb7cc7294, arg=0xb7cc5fec, kw=0x0) at Objects/abstract.c:1860 ---------------------------------------------------------------------- Comment By: Mike Klaas (mklaas) Date: 2006-10-17 19:23 Message: Logged In: YES user_id=1611720 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208400192 (LWP 26235)] 0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at Python/traceback.c:94 94 if ((next != NULL && !PyTraceBack_Check(next)) || (gdb) bt #0 0x080e4296 in PyTraceBack_Here (frame=0x9c2d7b4) at Python/traceback.c:94 #1 0x080b9ab7 in PyEval_EvalFrameEx (f=0x9c2d7b4, throwflag=1) at Python/ceval.c:2459 #2 0x08101a40 in gen_send_ex (gen=0xb64f880c, arg=0x81333e0, exc=1) at Objects/genobject.c:82 #3 0x08101c0f in gen_close (gen=0xb64f880c, args=0x0) at Objects/genobject.c:128 #4 0x08101cde in gen_del (self=0xb64f880c) at Objects/genobject.c:163 #5 0x0810195b in gen_dealloc (gen=0xb64f880c) at Objects/genobject.c:31 #6 0x080b9912 in PyEval_EvalFrameEx (f=0x9c2802c, throwflag=1) at Python/ceval.c:2491 #7 0x08101a40 in gen_send_ex (gen=0xb64f362c, arg=0x81333e0, exc=1) at Objects/genobject.c:82 #8 0x08101c0f in gen_close (gen=0xb64f362c, args=0x0) at Objects/genobject.c:128 #9 0x08101cde in gen_del (self=0xb64f362c) at Objects/genobject.c:163 #10 0x0810195b in gen_dealloc (gen=0xb64f362c) at Objects/genobject.c:31 #11 0x080815b9 in dict_dealloc (mp=0xb64f4a44) at Objects/dictobject.c:801 #12 0x080927b2 in subtype_dealloc (self=0xb64f340c) at Objects/typeobject.c:686 #13 0x0806028d in instancemethod_dealloc (im=0xb796a0cc) at Objects/classobject.c:2285 #14 0x080815b9 in dict_dealloc (mp=0xb64f78ac) at Objects/dictobject.c:801 #15 0x080927b2 in subtype_dealloc (self=0xb64f810c) at Objects/typeobject.c:686 #16 0x081028c5 in frame_dealloc (f=0x9c272bc) at Objects/frameobject.c:416 #17 0x080e41b1 in tb_dealloc (tb=0xb799166c) at Python/traceback.c:34 #18 0x080e41c2 in tb_dealloc (tb=0xb4071284) at Python/traceback.c:33 #19 0x080e41c2 in tb_dealloc (tb=0xb7991824) at Python/traceback.c:33 #20 0x08080dca in insertdict (mp=0xb7f56824, key=0xb3fb9930, hash=1492466088, value=0xb3fb9914) at Objects/dictobject.c:394 #21 0x080811a4 in PyDict_SetItem (op=0xb7f56824, key=0xb3fb9930, value=0xb3fb9914) at Objects/dictobject.c:619 #22 0x08082dc6 in PyDict_SetItemString (v=0xb7f56824, key=0x8129284 "exc_traceback", item=0xb3fb9914) at Objects/dictobject.c:2103 #23 0x080e2837 in PySys_SetObject (name=0x8129284 "exc_traceback", v=0xb3fb9914) at Python/sysmodule.c:82 #24 0x080bc9e5 in PyEval_EvalFrameEx (f=0x9c10e7c, throwflag=0) at Python/ceval.c:2954 #25 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc890, globals=0xb7bbe57c, locals=0x0, args=0x9b8e2ac, argcount=1, kws=0x9b8e2b0, kwcount=0, defs=0xb7b7aed8, defcount=1, closure=0x0) at Python/ceval.c:2833 #26 0x080bd62a in PyEval_EvalFrameEx (f=0x9b8e16c, throwflag=0) at Python/ceval.c:3662 #27 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7bbc848, globals=0xb7bbe57c, locals=0x0, args=0xb7af9d58, argcount=1, kws=0x9b7a818, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2833 #28 0x08104083 in function_call (func=0xb7b79c34, arg=0xb7af9d4c, kw=0xb7962c64) at Objects/funcobject.c:517 #29 0x0805a660 in PyObject_Call (func=0xb7b79c34, arg=0xb7af9d4c, kw=0xb7962c64) at Objects/abstract.c:1860 #30 0x080bcb4b in PyEval_EvalFrameEx (f=0x9b82c0c, throwflag=0) at Python/ceval.c:3846 #31 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7cd6608, globals=0xb7cd4934, locals=0x0, args=0x9b7765c, argcount=2, kws=0x9b77664, kwcount=0, defs=0x0, defcount=0, closure=0xb7cfe874) at Python/ceval.c:2833 #32 0x080bd62a in PyEval_EvalFrameEx (f=0x9b7751c, throwflag=0) at Python/ceval.c:3662 #33 0x080bdf70 in PyEval_EvalFrameEx (f=0x9a9646c, throwflag=0) at Python/ceval.c:3652 #34 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39728, globals=0xb7f6ca44, locals=0x0, args=0x9b7a00c, argcount=0, kws=0x9b7a00c, kwcount=0, defs=0x0, defcount=0, closure=0xb796410c) at Python/ceval.c:2833 #35 0x080bd62a in PyEval_EvalFrameEx (f=0x9b79ebc, throwflag=0) at Python/ceval.c:3662 #36 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f39770, globals=0xb7f6ca44, locals=0x0, args=0x99086c0, argcount=0, kws=0x99086c0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2833 #37 0x080bd62a in PyEval_EvalFrameEx (f=0x9908584, throwflag=0) at Python/ceval.c:3662 #38 0x080bfda3 in PyEval_EvalCodeEx (co=0xb7f397b8, globals=0xb7f6ca44, locals=0xb7f6ca44, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2833 ---Type to continue, or q to quit--- #39 0x080bff32 in PyEval_EvalCode (co=0xb7f397b8, globals=0xb7f6ca44, locals=0xb7f6ca44) at Python/ceval.c:494 #40 0x080ddff1 in PyRun_FileExFlags (fp=0x98a4008, filename=0xbfffd4a3 "scoreserver.py", start=257, globals=0xb7f6ca44, locals=0xb7f6ca44, closeit=1, flags=0xbfffd298) at Python/pythonrun.c:1264 #41 0x080de321 in PyRun_SimpleFileExFlags (fp=Variable "fp" is not available. ) at Python/pythonrun.c:870 #42 0x08056ac4 in Py_Main (argc=1, argv=0xbfffd334) at Modules/main.c:496 #43 0x00a69d5f in __libc_start_main () from /lib/libc.so.6 #44 0x08056051 in _start () ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470 From noreply at sourceforge.net Mon Nov 27 19:51:55 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Nov 2006 10:51:55 -0800 Subject: [ python-Bugs-1603789 ] grammatical error in Python Library Reference::Tkinter Message-ID: Bugs item #1603789, was opened at 2006-11-27 15:53 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603789&group_id=5470 Please note that this 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 Private: No Submitted By: Gabriel M. Elder (eldergabriel) Assigned to: Nobody/Anonymous (nobody) Summary: grammatical error in Python Library Reference::Tkinter Initial Comment: It's located here: http://www.python.org/doc/current/lib/node690.html "Flags are proceeded by a `-', like Unix shell command flags, and values are put in quotes if they are more than one word." "proceeded" should be "preceded" ---------------------------------------------------------------------- >Comment By: Georg Brandl (gbrandl) Date: 2006-11-27 18:51 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the report, fixed in rev. 52850, 52851 (2.5). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603789&group_id=5470 From noreply at sourceforge.net Tue Nov 28 04:20:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 27 Nov 2006 19:20:08 -0800 Subject: [ python-Bugs-1595822 ] read() in windows stops on chr(26) Message-ID: <200611280320.kAS3K8uA022251@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1595822, was opened at 2006-11-13 11:17 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595822&group_id=5470 Please note that this 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: Invalid Priority: 5 Private: No Submitted By: reson5 (reson5) Assigned to: Nobody/Anonymous (nobody) Summary: read() in windows stops on chr(26) Initial Comment: >From standard distribution (installation through .exe file): open() function in Windows (I have win2k and xp) opens files in text mode and stops on chr(26). I cannot parse a binary file (!). On Linux all works fine. Regards, Reson5 ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2006-11-27 19:20 Message: Logged In: YES user_id=1312539 Originator: NO 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-11-13 11:29 Message: Logged In: YES user_id=849994 chr(26) or Ctrl+Z is the end-of-file character in Windows, for text-mode files. If you open the file in binary mode, e.g. with open("filename", "rb"), there should be no problems with reading the chr(26). ---------------------------------------------------------------------- Comment By: reson5 (reson5) Date: 2006-11-13 11:20 Message: Logged In: YES user_id=1355850 To clarify, The behavior is not uniform on Linux it opens in binary and on windows in text (!) Regards, Reson5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595822&group_id=5470 From noreply at sourceforge.net Tue Nov 28 16:17:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Nov 2006 07:17:42 -0800 Subject: [ python-Bugs-1519816 ] urllib2 proxy does not work in 2.4.3 Message-ID: Bugs item #1519816, was opened at 2006-07-10 10:29 Message generated for change (Comment added) made by jerrykhan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Michal Niklas (mniklas) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 proxy does not work in 2.4.3 Initial Comment: My python app had to retrieve some web pages and while our network environment requires proxy it uses urllib2 opener (source is in attachment). It worked very well on older Python interpreters: ActivePython 2.4.2 Build 248 (ActiveState Corp.) based on Python 2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v.1310 32 bit (Intel)] on win32 It works on linux with 2.3 and 2.4.1: Python 2.4.1 (#2, May 5 2005, 11:32:06) [GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2 But it does not work with newest 2.4.3 on Linux: Python 2.4.3 (#1, Jul 10 2006, 09:57:52) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Desired result: isof-mark:~# python2.3 proxy_bug.py trying http://www.python.org ... OK. We have reply from http://www.python.org. Size: 13757 [b] design by pollenation Copyright ?? 1990-2006, Python Software Foundation
Legal Statements isof-mark:~# /usr/local/bin/python proxy_bug.py trying http://www.python.org ... Traceback (most recent call last): File "proxy_bug.py", line 37, in ? get_page() File "proxy_bug.py", line 27, in get_page f = urllib2.urlopen(request) File "/usr/local/lib/python2.4/urllib2.py", line 130, in urlopen return _opener.open(url, data) File "/usr/local/lib/python2.4/urllib2.py", line 364, in open response = meth(req, response) File "/usr/local/lib/python2.4/urllib2.py", line 471, in http_response response = self.parent.error( File "/usr/local/lib/python2.4/urllib2.py", line 402, in error return self._call_chain(*args) File "/usr/local/lib/python2.4/urllib2.py", line 337, in _call_chain result = func(*args) File "/usr/local/lib/python2.4/urllib2.py", line 480, in http_error_default raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) urllib2.HTTPError: HTTP Error 407: Proxy Authentication Required I have raported it on ActiveState bug list (http:// bugs.activestate.com/show_bug.cgi?id=47018) while I first spot this bug on their destribution but it seems that bug is in others distributions too. Regards, Michal Niklas ---------------------------------------------------------------------- Comment By: JerryKhan (jerrykhan) Date: 2006-11-28 16:17 Message: Logged In: YES user_id=867168 Originator: NO Hello, In my sens in a general manner there is something wrong in the urllib2 http code: But this may depends on the environment (I am not an expert in urllib) Here are my tests : using python 2.4.2 on Windows XP These simple codes failed with a 407 http error : Example E1: import urllib2 as URL a=URL.urlopen("http://lan_apache_url") print a.read() OR example E2: import urllib2 as URL r=URL.Request("http://lan_apache_url") a=URL.urlopen(r) print a.read() But succeed with urllib example E3 import urllib a=urllib.urlopen("http://lan_apache_url") print a.read() Notice that different code lines are minimal E1 and E3 are close: Notice also that I'm try to access a lan apache server which is not behind a Proxy. And I don't want to access to any Proxy (like exclusion string in IExplorer) But I found also that If I try to access to a protected link with HTTPS ... on the LAN, there is not problem. The issue is really on the HTTP interpreter or during the configuration of the URL opener. In the same time, some of my programs are able to access to Internet servers using the current Proxy server without any problem. For that, I use: import urllib2 as URL URL.install_opener(URL.build_opener( s.https_handler, s.proxy_auth_handler, s.cookie_handler)) Well, I developed a workaround in my programs ... to use urllib instead of urllib2 in the case where I try to access the LAN (in fact when I don't want to configure the Proxy server, or when the URL match my own proxy exclusion list.) I espect this will help python urllib2 experts to find the issue. J?r?me Vacher alias jerrykhan the foolish dracomorpheus of the emerald dragon dynasty. ---------------------------------------------------------------------- Comment By: Michal Niklas (mniklas) Date: 2006-07-21 09:59 Message: Logged In: YES user_id=226518 I have just installed new virtual machine with Python 2.5b2 and my program works. It seems that only 2.4.3 is broken. Regards, Michal ---------------------------------------------------------------------- Comment By: John J Lee (jjlee) Date: 2006-07-20 20:09 Message: Logged In: YES user_id=261020 You're sure you didn't copy over the urllib2.py from 2.5b2 also? That might make the bug appear to go away, when really it's still there. The way to be sure is to try it on a different machine. Thanks for your report. ---------------------------------------------------------------------- Comment By: Michal Niklas (mniklas) Date: 2006-07-19 13:12 Message: Logged In: YES user_id=226518 I have checked that the last wersion my script works with is 2.4.2 and copied that version urllib2.py to 2.4.3 Lib directory. It works again. The only change in urllib2.py is in retry_http_basic_auth(), line 723: 2.4.2 user,pw = self.passwd.find_user_password(realm, host) 2.4.3 user, pw = self.passwd.find_user_password(realm, req.get_full_url()) So "host" is replaced by "req.get_full_url()". Checked again with 2.5b2 and it works! Probably I destroyed my test environment and tested it wrong way :( So the problem is only with 2.4.3. Previous versions and 2.5b works well. Regards, Michal Niklas ---------------------------------------------------------------------- Comment By: Michal Niklas (mniklas) Date: 2006-07-13 12:09 Message: Logged In: YES user_id=226518 2.5b2 does not work any better: Python 2.5b2 (r25b2:50512, Jul 11 2006, 10:16:14) [MSC v.1310 32 bit (Intel)] on win32 Result is the same as in 2.5b1 :( ---------------------------------------------------------------------- Comment By: Michal Niklas (mniklas) Date: 2006-07-11 08:27 Message: Logged In: YES user_id=226518 Tried it with 2.5 beta 1 and it is not better :( c:\tools\pyscripts\scripts>c:\python25\python2.5 Python 2.5b1 (r25b1:47027, Jun 20 2006, 09:31:33) [MSC v.1310 32 bit (Intel)] on win32 c:\tools\pyscripts\scripts>c:\python25\python2.5 proxy_bug.py trying http://www.python.org ... Traceback (most recent call last): File "proxy_bug.py", line 37, in get_page() File "proxy_bug.py", line 27, in get_page f = urllib2.urlopen(request) File "c:\python25\lib\urllib2.py", line 121, in urlopen return _opener.open(url, data) File "c:\python25\lib\urllib2.py", line 380, in open response = meth(req, response) File "c:\python25\lib\urllib2.py", line 491, in http_response 'http', request, response, code, msg, hdrs) File "c:\python25\lib\urllib2.py", line 412, in error result = self._call_chain(*args) File "c:\python25\lib\urllib2.py", line 353, in _call_chain result = func(*args) File "c:\python25\lib\urllib2.py", line 831, in http_error_407 authority, req, headers) File "c:\python25\lib\urllib2.py", line 795, in http_error_auth_reqed return self.retry_http_basic_auth(host, req, realm) File "c:\python25\lib\urllib2.py", line 805, in retry_http_basic_auth return self.parent.open(req) File "c:\python25\lib\urllib2.py", line 380, in open response = meth(req, response) File "c:\python25\lib\urllib2.py", line 491, in http_response 'http', request, response, code, msg, hdrs) File "c:\python25\lib\urllib2.py", line 418, in error return self._call_chain(*args) File "c:\python25\lib\urllib2.py", line 353, in _call_chain result = func(*args) File "c:\python25\lib\urllib2.py", line 499, in http_error_default raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) urllib2.HTTPError: HTTP Error 407: Proxy Authentication Required ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-07-10 14:49 Message: Logged In: YES user_id=849994 Can you please try with 2.5b1? A lot of urllib2 related bugs have been fixed before this release. ---------------------------------------------------------------------- Comment By: Michal Niklas (mniklas) Date: 2006-07-10 10:41 Message: Logged In: YES user_id=226518 Cannot add attachment via upload so I put it here: #!/usr/bin/python # -*- coding: cp1250 -*- import urllib import urllib2 def get_page(): url = 'http://www.python.org' print "trying %s ..." % (url) # Setup proxy & authentication proxy = "poczta.heuthes:8080" usr1 = "USER" pass1 = "PASSWD" proxy_handler = urllib2.ProxyHandler({"http" : "http:/ /" + proxy}) pass_mgr = urllib2.HTTPPasswordMgrWithDefaultRealm() pass_mgr.add_password(None, "http://" + proxy, usr1, pass1) pass_mgr.add_password(None, proxy, usr1, pass1) auth_handler = urllib2.HTTPBasicAuthHandler(pass_mgr) proxy_auth_handler = urllib2.ProxyBasicAuthHandler(pass_mgr) # Now build a new URL opener and install it opener = urllib2.build_opener(proxy_handler, proxy_auth_handler, auth_handler, urllib2.HTTPHandler) urllib2.install_opener(opener) request = urllib2.Request(url) f = urllib2.urlopen(request) data = f.read() print "OK. We have reply from %s.\nSize: %d [b]" % (url, len(data)) if len(data) < 400: print data else: print data[:200] print "..." print data[-200:] get_page() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1519816&group_id=5470 From noreply at sourceforge.net Tue Nov 28 21:45:58 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Nov 2006 12:45:58 -0800 Subject: [ python-Bugs-1563807 ] _ctypes built with GCC on AIX 5.3 fails with ld ffi error Message-ID: Bugs item #1563807, was opened at 2006-09-23 02:07 Message generated for change (Comment added) made by theller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 Please note that this 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 Private: No Submitted By: Daniel Clark (djbclark) Assigned to: Thomas Heller (theller) Summary: _ctypes built with GCC on AIX 5.3 fails with ld ffi error Initial Comment: Build of Python 2.5 on AIX 5.3 with GCC (tried multiple versions: 3.3.2 from Bull Freeware, 4.1.0 and 4.1.1 from UCLA) fails with the below error message. Tried various configure lines, which all get to the same error, the most simple being: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ (With gcc 3.3.2 I also needed --without-threads) [...] building '_ctypes' extension ./Modules/ld_so_aix gcc -pthread -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/callbacks.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/usr/ local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 Re-running the failing stanza with -Wl,-bnoquiet gives: (ld): halt 4 (ld): setopt r/o->w (ld): setopt nodelcsect (ld): setfflag 4 (ld): savename build/lib.aix-5.3-2.5/_ctypes.so (ld): filelist 17 3 (ld): setopt noprogram (ld): entry init_ctypes ENTRY: Entry point set to init_ctypes (ld): i /lib/crt0_r.o (ld): i /tmp//ccigrpfq.o (ld): lib /usr/lib/libm.a (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/_ctypes.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callbacks.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/callproc.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/stgdict.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/cfield.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/malloc_closure.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ ffi_darwin.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/aix.o (ld): i build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Modules/_ctypes/libffi/src/powerpc/ aix_closure.o (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc.a (ld): i /usr/local/encap/gcc-4.1.1/bin/../lib/gcc/ powerpc-ibm-aix5.3.0.0/4.1.1/pthread/libgcc_eh.a (ld): lib /usr/lib/libpthreads.a (ld): lib /usr/lib/libc.a LIBRARY: Shared object libpthreads.a[shr_comm.o]: 173 symbols imported. LIBRARY: Shared object libpthreads.a[shr_xpg5.o]: 161 symbols imported. LIBRARY: Shared object libc.a[shr.o]: 2820 symbols imported. LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported. LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported. LIBRARY: Shared object libc.a[aio.o]: 14 symbols imported. LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported. LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported. LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported. FILELIST: Number of previously inserted files processed: 17 (ld): imports Modules/python.exp IMPORTS: Symbols imported from import file Modules/ python.exp: 1034 (ld): exports _ctypes.exp EXPORTS: Symbols exported: 57 (ld): initfini _GLOBAL__FI__ctypes_so _GLOBAL__FD__ctypes_so (ld): resolve RESOLVE: 895 of 7035 symbols were kept. (ld): addgl /usr/lib/glink.o ADDGL: Glink code added for 125 symbols. (ld): er full ld: 0711-318 ERROR: Undefined symbols were found. The following symbols are in error: Symbol Inpndx TY CL Source- File(Object-File) OR Import-File{Shared-object} RLD: Address Section Rld-type Referencing Symbol ------------------------------------------------------ ---------------------------------------- .ffi_prep_cif_machdep [8] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ prep_cif.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python -2.5/Modules/_ctypes/libffi/src/prep_cif.o) 00000a44 .text R_RBR [556] .ffi_prep_cif .ffi_call [140] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callproc.c(build/temp.aix-5.3-2.5/usr/local/src/python- 2.5/Python-2.5/Module s/_ctypes/callproc.o) 00001888 .text R_RBR [913] ._CallProc 00001980 .text R_RBR [913] ._CallProc .ffi_prep_closure [36] ER PR /usr/local/ src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.c(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modul es/_ctypes/callbacks.o) 00000274 .text R_RBR [621] .AllocFunctionCallback .ffi_closure_helper_DARWIN [2] ER PR aix_closure.S(build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/ powerpc/aix_closure.o) 00000070 .text R_RBR [6] .ffi_closure_ASM ER: The return code is 8.ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN collect2: ld returned 8 exit status ---------------------------------------------------------------------- >Comment By: Thomas Heller (theller) Date: 2006-11-28 21:45 Message: Logged In: YES user_id=11105 Originator: NO This bug should be fixed now in SVN rev 52855 (trunk) and rev 52856 (release25-maint branch). Thanks. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-16 20:22 Message: Logged In: YES user_id=1645242 Originator: NO /home/rvjif00 $ gcc --version 2.9-aix51-020209 /home/rvjif00 $ gcc -v -c empty.c Reading specs from /opt/freeware/GNUPro/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/specs gcc version 2.9-aix51-020209 /opt/freeware/GNUPro/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/cpp -lang-c -v -iprefix /bin/../lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/ -D__GNUC__=2 -D__GNUC_MINOR__=9 -D_IBMR2 -D_POWER -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 -D_AIX51 -D_LONG_LONG -D_IBMR2 -D_POWER -D_AIX -D_AIX32 -D_AIX41 -D_AIX43 -D_AIX51 -D_LONG_LONG -Asystem(unix) -Asystem(aix) -D__CHAR_UNSIGNED__ -D_ARCH_COM empty.c /tmp/ccTtoObS.i GNU CPP version 2.9-aix51-020209 #include "..." search starts here: #include <...> search starts here: /opt/freeware/GNUPro/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/include /usr/include End of search list. The following default directories have been omitted from the search path: /opt/freeware/GNUPro/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/../../../../include/g++-3 /opt/freeware/GNUPro/include /opt/freeware/GNUPro/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/../../../../powerpc-ibm-aix5.1.0.0/include End of omitted list. /opt/freeware/GNUPro/lib/gcc-lib/powerpc-ibm-aix5.1.0.0/2.9-aix51-020209/cc1 /tmp/ccTtoObS.i -quiet -dumpbase empty.c -version -o /tmp/cc28GcTD.s GNU C version 2.9-aix51-020209 (powerpc-ibm-aix5.1.0.0) compiled by GNU C version 2.9-aix51-020209. as -u -mcom -o empty.o /tmp/cc28GcTD.s ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-15 21:59 Message: Logged In: YES user_id=21627 Originator: NO What gcc version is this? In older versions, you have to do gcc -v -c empty.c and watch the verbose output. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-15 14:36 Message: Logged In: YES user_id=11105 Originator: NO Yes ;-), although I would have expected that 'gcc -E -dD empty.c' would have printed something. Does 'touch empty.c; cpp -dM empty.c' print something? ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-15 14:00 Message: Logged In: YES user_id=1645242 Originator: NO Something like this? ~ $ touch empty.c ~ $ gcc -E -dD empty.c # 1 "empty.c" ~ $ cat empty.c ~ $ ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-15 11:05 Message: Logged In: YES user_id=11105 Originator: NO memotype, can you please do what loewis suggested and report back: > Please compile an empty file with "gcc -E -dD empty.c" to find out what > defines are builtin. It is very likely that the symbol we need is a builtin symbol of the compiler, and not a symbol defined in some of the header files. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 20:29 Message: Logged In: YES user_id=1645242 Originator: NO Ohh, and before you ask (I forgot to mention): grepping for "ppc" (with -i) doesn't yield any more results. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 20:25 Message: Logged In: YES user_id=1645242 Originator: NO I'm sorry, I meant __ppc__, it was the __ppc__ lines that I removed. As for PPC specific defines, I can't find any that work, but grepping around in /usr/include shows: /usr/include $ grep -i powerpc * aouthdr.h: * Defines for the POWER and PowerPC CPU Types aouthdr.h:#define TCPU_PPC 1 /* PowerPC common architecture 32 bit mode */ aouthdr.h:#define TCPU_PPC64 2 /* PowerPC common architecture 64 bit mode */ aouthdr.h:#define TCPU_COM 3 /* POWER and PowerPC architecture common */ aouthdr.h: /* and PowerPC architecture implementations */ aouthdr.h:#define TCPU_601 6 /* 601 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_603 7 /* 603 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_604 8 /* 604 implementation of PowerPC architecture */ aouthdr.h:#define TCPU_620 16 /* 620 implementation of PowerPC 64-bit architecture */ aouthdr.h:#define TCPU_A35 17 /* A35 implementation of PowerPC 64-bit architecture */ filehdr.h:/* IBM POWER and PowerPC */ frs.h:| - rom_scan_R2_6002_block_t (PowerPC devices) frs.h:| - rom_scan_R2_6003_block_t (60x PowerPC devices) frs.h:| The PowerPC 601 Bus has such characteristics. frs.h:| that matches the PowerPC 60X Bus and PowerPC System Architecture frs_60x.h: | as defined by PowerPC System ARch and unique frs_60x.h:| PowerPC Feature/VPD Header reloc.h: * POWER and PowerPC - relocation types I would love to send you a copy of the aouthdr.h, but I'm not sure if that would violate any licenses, so I will have to leave the rest to you guys to look for some definitive documentation as to how to detect ppc from defines. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-14 20:08 Message: Logged In: YES user_id=21627 Originator: NO Please compile an empty file with "gcc -E -dD empty.c" to find out what defines are builtin. ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 19:47 Message: Logged In: YES user_id=11105 Originator: NO Hm, I was asking for '__ppc__', not '__aix__'. Can you look for processor specific defines, please? ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 19:35 Message: Logged In: YES user_id=1645242 Originator: NO _AIX however, /is/ defined, so maybe s/__aix__/_AIX/g? ~/Python-2.5 $ cat <<. > test.c > int main() { > #ifdef _AIX > return 0; > #endif > #ifndef _AIX > return 1; > #endif > } > . ~/Python-2.5 $ gcc -o test test.c ~/Python-2.5 $ ./test ~/Python-2.5 $ echo $? 0 ~/Python-2.5 $ ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 19:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 19:28 Message: Logged In: YES user_id=1645242 Originator: NO That seems to have done the trick actually. __aix__ is in fact not defined on AIX 5.2 (cannot varify on 5.3) and removing the #ifdefs in the suggested file allows for a clean build: ~/Python-2.5 $ ./python Python 2.5 (r25:51908, Nov 14 2006, 13:19:33) [GCC 2.9-aix51-020209] on aix5 Type "help", "copyright", "credits" or "license" for more information. >>> import ctypes >>> dir (ctypes) ['ARRAY', 'ArgumentError', 'Array', 'BigEndianStructure', 'CDLL', 'CFUNCTYPE', 'DEFAULT_MODE', 'LibraryLoader', 'LittleEndianStructure', 'POINTER', 'PYFUNCTYPE', 'PyDLL', 'RTLD_GLOBAL', 'RTLD_LOCAL', 'SetPointerType', 'Structure', 'Union', '_CFuncPtr', '_FUNCFLAG_CDECL', '_FUNCFLAG_PYTHONAPI', '_Pointer', '_SimpleCData', '__builtins__', '__doc__', '__file__', '__name__', '__path__', '__version__', '__warningregistry__', '_c_functype_cache', '_calcsize', '_cast', '_cast_addr', '_ctypes_version', '_dlopen', '_endian', '_memmove_addr', '_memset_addr', '_os', '_pointer_type_cache', '_string_at', '_string_at_addr', '_sys', '_wstring_at', '_wstring_at_addr', 'addressof', 'alignment', 'byref', 'c_buffer', 'c_byte', 'c_char', 'c_char_p', 'c_double', 'c_float', 'c_int', 'c_int16', 'c_int32', 'c_int64', 'c_int8', 'c_long', 'c_longlong', 'c_short', 'c_size_t', 'c_ubyte', 'c_uint', 'c_uint16', 'c_uint32', 'c_uint64', 'c_uint8', 'c_ulong', 'c_ulonglong', 'c_ushort', 'c_void_p', 'c_voidp', 'c_wchar', 'c_wchar_p', 'cast', 'cdll', 'create_string_buffer', 'create_unicode_buffer', 'memmove', 'memset', 'pointer', 'py_object', 'pydll', 'pythonapi', 'resize', 'set_conversion_mode', 'sizeof', 'string_at', 'wstring_at'] >>> ---------------------------------------------------------------------- Comment By: Thomas Heller (theller) Date: 2006-11-14 18:05 Message: Logged In: YES user_id=11105 Well, there is certainly a diff in noctypes.diff. If your patch program cannot handle it, you may want to apply it manually (basically you have to remove/comment out two sections of code in setup.py). It seems that there are actually two bugs: 1. setup.py doesn't continue after trying to import the _ctypes extension. No idea why, but somewhere something exists the process. 2. _ctypes.so does not build (or better fails to load) because of missing symbols: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep ld: 0711-317 ERROR: Undefined symbol: .ffi_call ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_closure ld: 0711-317 ERROR: Undefined symbol: .ffi_closure_helper_DARWIN I have no access to an AIX system, do I cannot try this out myself. One thing that comes to mind: These functions are implemented in the file Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c. This file is compiled, without errors. One problem could be that the whole file contents are included in an #ifdef block like this: #ifdef __ppc__ ... #endif Can it be that __ppc__ is not defined on this system? Can someone try out to build with these two lines removed? Thanks. ---------------------------------------------------------------------- Comment By: Memotype (memotype) Date: 2006-11-14 16:55 Message: Logged In: YES user_id=1645242 What is the status on this bug? I tried the work around, but patch doesn't like the diff file provided, says "Processing... I cannot find a patch in there anywhere." ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:55 Message: Logged In: YES user_id=129055 Build finished running; full log attached as python-2.5- ctypes.log.gz. Relevent lines are: ld: 0711-317 ERROR: Undefined symbol: .ffi_prep_cif_machdep [... more ld errors ...] collect2: ld returned 8 exit status *** WARNING: renaming "_ctypes" since importing it failed: Could not load module build/lib.aix-5.3-2.5. System error: No such file or directory error: No such file or directory gmake: *** [sharedmods] Error 1 And at this point gmake exits and the build stops. Running gmake again just causes the same error to pop up. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:29 Message: Logged In: YES user_id=129055 Ah, well there is a bug then... setup.py does not continue on its own. I've added an attachement of a successful full build log (built with the noctypes patch), and will attach a second full build log that shows the build failing on the error when it finishes running in 10-20 minutes... ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 14:14 Message: Logged In: YES user_id=21627 No; setup.py should continue on its own. If it doesn't, that's a bug. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 14:06 Message: Logged In: YES user_id=129055 loewis: No, the ctypes error messages cause the build to fail. Are you saying to use "gmake -k" or something like that? ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-09-23 13:15 Message: Logged In: YES user_id=21627 You don't need to disable it. It will print error messages, but you can just ignore them if you don't need the ctypes module. ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 05:44 Message: Logged In: YES user_id=129055 The only way I could figure out to disable ctypes was via a patch to setup.py (included as noctypes.diff). With this patch applied, Python 2.5 compiles without issues on AIX 5.3 / GCC 4.1.1, and seems to work fine (except for ctypes of course, and probably some things that depend on ctypes are also broken). (For the exact build paramaters used, see attached python-2.5.ep) ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 04:07 Message: Logged In: YES user_id=129055 As a temporary workaround, is there any way to just disable building of the ctypes module? ---------------------------------------------------------------------- Comment By: Daniel Clark (djbclark) Date: 2006-09-23 02:48 Message: Logged In: YES user_id=129055 Did a search of the bug database, and found some simular bugs: http://python.org/sf/1530448 http://python.org/sf/1544339 http://python.org/sf/1529269 Also tried with --with-system-ffi and some other options, but got same error: ./configure --disable-ipv6 --with-gcc --with-cxx=g++ -- disable-universalsdk --disable-framework --disable-toolbox- glue --with-system-ffi --without-threads Tried adding -Wl,-mimpure-text as in r51113, but that just caused an error (I might be doing it wrong or something, specifics below) # ./Modules/ld_so_aix gcc -Wl,-mimpure-text -bI:Modules/ python.exp build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/_ctypes.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ callbacks.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/callproc.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ stgdict.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/ Python-2.5/Modules/_ctypes/cfield.o build/temp.aix-5.3-2.5/ usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ malloc_closure.o build/temp.aix-5.3-2.5/usr/local/src/ python-2.5/Python-2.5/Modules/_ctypes/libffi/src/prep_cif.o build/temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/ffi_darwin.o build/ temp.aix-5.3-2.5/usr/local/src/python-2.5/Python-2.5/ Modules/_ctypes/libffi/src/powerpc/aix.o build/temp.aix-5.3- 2.5/usr/local/src/python-2.5/Python-2.5/Modules/_ctypes/ libffi/src/powerpc/aix_closure.o -L/usr/local/lib -o build/ lib.aix-5.3-2.5/_ctypes.so ld: 0706-027 The -i flag is ignored. ld: 0706-012 The -p flag is not recognized. collect2: ld returned 255 exit status ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563807&group_id=5470 From noreply at sourceforge.net Tue Nov 28 22:56:36 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Nov 2006 13:56:36 -0800 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 Private: No 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-11-29 08:56 Message: Logged In: YES user_id=6405 Originator: YES I just successfully built ctypes 1.0.1 on a MacBook (ie. x86) OS X machine. I don't know whether it builds on a PPC machine. ---------------------------------------------------------------------- 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 Tue Nov 28 23:17:14 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Nov 2006 14:17:14 -0800 Subject: [ python-Bugs-1604851 ] subprocess.Popen closes fds for sys.stdout or sys.stderr Message-ID: Bugs item #1604851, was opened at 2006-11-28 14: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=1604851&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Nishkar Grover (ngrover) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess.Popen closes fds for sys.stdout or sys.stderr Initial Comment: I found a problem in subprocess.Popen's _execute_child() method for POSIX, where the child process will close the fds for sys.stdout and/or sys.stderr if I use those as stdout and/or stderr when creating a subprocess.Popen object. Here's what I saw by default when using the 2.4.4 version of Python... % ./python Python 2.4.4 (#1, Nov 28 2006, 14:08:29) [GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> >>> import sys, subprocess >>> uname = subprocess.Popen('uname -a', shell=True, stdout=sys.stdout) >>> uname: write error: Bad file descriptor >>> Then, I updated subprocess.py and made the following changes... % diff subprocess.py subprocess.py.orig 924c924 < # fd more than once and don't close sys.stdout or sys.stderr. --- > # fd more than once. 927c927 < if c2pwrite and c2pwrite not in (p2cread, sys.stdout.fileno(), sys.stderr.fileno()): --- > if c2pwrite and c2pwrite not in (p2cread,): 929c929 < if errwrite and errwrite not in (p2cread, c2pwrite, sys.stdout.fileno(), sys.stderr.fileno()): --- > if errwrite and errwrite not in (p2cread, c2pwrite): After that, I saw the following... % ./python Python 2.4.4 (#1, Nov 28 2006, 14:08:29) [GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> >>> import sys, subprocess >>> uname = subprocess.Popen('uname -a', shell=True, stdout=sys.stdout) >>> Linux schnauzer 2.6.9-42.0.2.ELsmp #1 SMP Thu Aug 17 18:00:32 EDT 2006 i686 i686 i386 GNU/Linux >>> I'm attaching the modified version of subprocess.py. Please consider adding this fix to future versions of Python. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1604851&group_id=5470 From noreply at sourceforge.net Tue Nov 28 23:32:21 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 28 Nov 2006 14:32:21 -0800 Subject: [ python-Bugs-1604862 ] _CRT_SECURE_NO_DEPRECATE macro redefinition with VC++ 8 Message-ID: Bugs item #1604862, was opened at 2006-11-28 22: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=1604862&group_id=5470 Please note that this 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 Private: No Submitted By: William Fulton (wsfulton) Assigned to: Nobody/Anonymous (nobody) Summary: _CRT_SECURE_NO_DEPRECATE macro redefinition with VC++ 8 Initial Comment: I'm getting this warning with VC++ 8 for all extension modules: e:\python25\include\pyconfig.h(42) : warning C4005: '_CRT_SECURE_NO_DEPRECATE' : macro redefinition .\example_wrap.cxx(124) : see previous definition of '_CRT_SECURE_NO_DEPRECATE' because Python.h defines this macro without checking that it is not already defined. Can you fix your headers so we don't get this warning? It is impossible to work around this problem when dealing with multiple versions of Python as we can't detect the version of Python until Python.h is parsed - a catch 22 situation. Can you use the same approach that we are using in SWIG? This is what we do: #if !defined(SWIG_NO_CRT_SECURE_NO_DEPRECATE) && defined(_MSC_VER) && !defined(_CRT_SECURE_NO_DEPRECATE) # define _CRT_SECURE_NO_DEPRECATE #endif Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1604862&group_id=5470 From noreply at sourceforge.net Wed Nov 29 09:20:32 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 00:20:32 -0800 Subject: [ python-Feature Requests-1602189 ] Suggest a textlist() method for ElementTree Message-ID: Feature Requests item #1602189, was opened at 2006-11-24 11:00 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1602189&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Hettinger (rhettinger) >Assigned to: Fredrik Lundh (effbot) Summary: Suggest a textlist() method for ElementTree Initial Comment: This patch has a implementation and example for a method to recursively extract prose from nested XML markup. This improves the utility of ElementTree for documents where otherwise contiguous PCDATA are broken-up by inspersed tags (e.g. xhtml or docbook fragments). See attached file or the ASPN recipe at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/498286 ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-29 09:20 Message: Logged In: YES user_id=21627 Originator: NO Why was this assigned to fdrake? Fredrik, can you please take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1602189&group_id=5470 From noreply at sourceforge.net Wed Nov 29 10:29:16 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 01:29:16 -0800 Subject: [ python-Bugs-1605110 ] logging %(module)s reporting wrong modules Message-ID: Bugs item #1605110, was opened at 2006-11-29 10: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=1605110&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Mad-Marty (mad-marty) Assigned to: Nobody/Anonymous (nobody) Summary: logging %(module)s reporting wrong modules Initial Comment: I recently upgraded from python 2.4.2 to 2.4.4 and the logging seems to be working wrong now. I have a formatter which uses the %(module)s and %(filename)s and the point to the wrong file/module. I have some plugins in .py files, which mainly have one class derived from threading.Thread. Those classes logging calls will now log as 2006-11-29 10:17:50 - threading.py - threading - INFO - ... instead of 2006-11-29 10:17:50 - myplugin.py - myplugin - INFO - ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1605110&group_id=5470 From noreply at sourceforge.net Wed Nov 29 10:32:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 01:32:15 -0800 Subject: [ python-Bugs-1605110 ] logging %(module)s reporting wrong modules Message-ID: Bugs item #1605110, was opened at 2006-11-29 10:29 Message generated for change (Comment added) made by mad-marty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1605110&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Mad-Marty (mad-marty) Assigned to: Nobody/Anonymous (nobody) Summary: logging %(module)s reporting wrong modules Initial Comment: I recently upgraded from python 2.4.2 to 2.4.4 and the logging seems to be working wrong now. I have a formatter which uses the %(module)s and %(filename)s and the point to the wrong file/module. I have some plugins in .py files, which mainly have one class derived from threading.Thread. Those classes logging calls will now log as 2006-11-29 10:17:50 - threading.py - threading - INFO - ... instead of 2006-11-29 10:17:50 - myplugin.py - myplugin - INFO - ... ---------------------------------------------------------------------- >Comment By: Mad-Marty (mad-marty) Date: 2006-11-29 10:32 Message: Logged In: YES user_id=1269426 Originator: YES Forgot to add, that is is the 2.4.4 windows package used on windows xp. ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1605110&group_id=5470 From noreply at sourceforge.net Wed Nov 29 11:02:06 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 02:02:06 -0800 Subject: [ python-Feature Requests-1602189 ] Suggest a textlist() method for ElementTree Message-ID: Feature Requests item #1602189, was opened at 2006-11-24 11:00 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1602189&group_id=5470 Please note that this 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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Raymond Hettinger (rhettinger) Assigned to: Fredrik Lundh (effbot) Summary: Suggest a textlist() method for ElementTree Initial Comment: This patch has a implementation and example for a method to recursively extract prose from nested XML markup. This improves the utility of ElementTree for documents where otherwise contiguous PCDATA are broken-up by inspersed tags (e.g. xhtml or docbook fragments). See attached file or the ASPN recipe at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/498286 ---------------------------------------------------------------------- >Comment By: Fredrik Lundh (effbot) Date: 2006-11-29 11:02 Message: Logged In: YES user_id=38376 Originator: NO This is pretty much identical to the gettext and flatten helpers in the ElementLib utility library (see effbot.org for links and code). The current plan is to make some of these available as helper functions in ElementTree 1.3 (=Python 2.6), rather than methods. I'm leaving this open as a reminder to self. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-29 09:20 Message: Logged In: YES user_id=21627 Originator: NO Why was this assigned to fdrake? Fredrik, can you please take a look? If not, please unassign. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1602189&group_id=5470 From noreply at sourceforge.net Wed Nov 29 13:02:42 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 04:02:42 -0800 Subject: [ python-Bugs-1605110 ] logging %(module)s reporting wrong modules Message-ID: Bugs item #1605110, was opened at 2006-11-29 10:29 Message generated for change (Comment added) made by mad-marty You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1605110&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Mad-Marty (mad-marty) Assigned to: Nobody/Anonymous (nobody) Summary: logging %(module)s reporting wrong modules Initial Comment: I recently upgraded from python 2.4.2 to 2.4.4 and the logging seems to be working wrong now. I have a formatter which uses the %(module)s and %(filename)s and the point to the wrong file/module. I have some plugins in .py files, which mainly have one class derived from threading.Thread. Those classes logging calls will now log as 2006-11-29 10:17:50 - threading.py - threading - INFO - ... instead of 2006-11-29 10:17:50 - myplugin.py - myplugin - INFO - ... ---------------------------------------------------------------------- >Comment By: Mad-Marty (mad-marty) Date: 2006-11-29 13:02 Message: Logged In: YES user_id=1269426 Originator: YES Checked again and found that the bug was introduced with Python 2.4.2. Last correctly working version is python-2.4.1.msi. ---------------------------------------------------------------------- Comment By: Mad-Marty (mad-marty) Date: 2006-11-29 10:32 Message: Logged In: YES user_id=1269426 Originator: YES Forgot to add, that is is the 2.4.4 windows package used on windows xp. ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1605110&group_id=5470 From noreply at sourceforge.net Wed Nov 29 22:12:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 13:12:26 -0800 Subject: [ python-Bugs-1604862 ] _CRT_SECURE_NO_DEPRECATE macro redefinition with VC++ 8 Message-ID: Bugs item #1604862, was opened at 2006-11-28 23:32 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1604862&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Extension Modules Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: William Fulton (wsfulton) Assigned to: Nobody/Anonymous (nobody) Summary: _CRT_SECURE_NO_DEPRECATE macro redefinition with VC++ 8 Initial Comment: I'm getting this warning with VC++ 8 for all extension modules: e:\python25\include\pyconfig.h(42) : warning C4005: '_CRT_SECURE_NO_DEPRECATE' : macro redefinition .\example_wrap.cxx(124) : see previous definition of '_CRT_SECURE_NO_DEPRECATE' because Python.h defines this macro without checking that it is not already defined. Can you fix your headers so we don't get this warning? It is impossible to work around this problem when dealing with multiple versions of Python as we can't detect the version of Python until Python.h is parsed - a catch 22 situation. Can you use the same approach that we are using in SWIG? This is what we do: #if !defined(SWIG_NO_CRT_SECURE_NO_DEPRECATE) && defined(_MSC_VER) && !defined(_CRT_SECURE_NO_DEPRECATE) # define _CRT_SECURE_NO_DEPRECATE #endif Thanks ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-29 22:12 Message: Logged In: YES user_id=21627 Originator: NO This was fixed in r52817 and r52818 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1604862&group_id=5470 From noreply at sourceforge.net Wed Nov 29 22:18:12 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 13:18:12 -0800 Subject: [ python-Bugs-1603527 ] Python socket library confused by IPV6 notation in /etc/host Message-ID: Bugs item #1603527, was opened at 2006-11-27 06:43 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Eric S. Raymond (esr) Assigned to: Nobody/Anonymous (nobody) Summary: Python socket library confused by IPV6 notation in /etc/host Initial Comment: Robert J.Berger reported this on the gpsd-dev mailing list of the GPSD project. "Until I changed the line in /etc/hosts from: ::1 localhost.localdomain localhost to: 127.0.0.1 localhost.localdomain localhost the gps.py [library distributed by the GPSD project] would fail when trying to open the socket connection to gpsd: File "/usr/local/bin/spGps.py", line 198, in __init__ self.connect(host, port) File "/usr/local/bin/spGps.py", line 237, in connect raise socket.error, msg socket.error: (111, 'Connection refused') This is with Python 2.4.4 under Red Hat Linux, kernel version not reported. Robert believes, and I concur, that this is not a GPSD bug. Rather, something lower-level -- possibly the Python socket library, possibly some C library it uses -- is having indigestion on the IPV6 notation. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-29 22:18 Message: Logged In: YES user_id=21627 Originator: NO Can you please report the values of "host" and "port" when that error is raised? ---------------------------------------------------------------------- Comment By: Eric S. Raymond (esr) Date: 2006-11-27 07:03 Message: Logged In: YES user_id=3060 Originator: YES Berger reports the kernel is 2.6.18. Fedora Core 6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&group_id=5470 From noreply at sourceforge.net Wed Nov 29 22:35:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 13:35:15 -0800 Subject: [ python-Bugs-1603527 ] Python socket library confused by IPV6 notation in /etc/host Message-ID: Bugs item #1603527, was opened at 2006-11-27 05:43 Message generated for change (Comment added) made by esr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Eric S. Raymond (esr) Assigned to: Nobody/Anonymous (nobody) Summary: Python socket library confused by IPV6 notation in /etc/host Initial Comment: Robert J.Berger reported this on the gpsd-dev mailing list of the GPSD project. "Until I changed the line in /etc/hosts from: ::1 localhost.localdomain localhost to: 127.0.0.1 localhost.localdomain localhost the gps.py [library distributed by the GPSD project] would fail when trying to open the socket connection to gpsd: File "/usr/local/bin/spGps.py", line 198, in __init__ self.connect(host, port) File "/usr/local/bin/spGps.py", line 237, in connect raise socket.error, msg socket.error: (111, 'Connection refused') This is with Python 2.4.4 under Red Hat Linux, kernel version not reported. Robert believes, and I concur, that this is not a GPSD bug. Rather, something lower-level -- possibly the Python socket library, possibly some C library it uses -- is having indigestion on the IPV6 notation. ---------------------------------------------------------------------- >Comment By: Eric S. Raymond (esr) Date: 2006-11-29 21:35 Message: Logged In: YES user_id=3060 Originator: YES host is 'localhost' port is 2947 What's going on here is that gps.py is a Python client module for a local daemon that monitors GPS devices on the host's serial and USB ports and presents output on port 2947. While it is possible to use gps.py to monitor a remote host, Berger wasn't doing that. The socket module threw an error while attempting to connect to localhost. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-29 21:18 Message: Logged In: YES user_id=21627 Originator: NO Can you please report the values of "host" and "port" when that error is raised? ---------------------------------------------------------------------- Comment By: Eric S. Raymond (esr) Date: 2006-11-27 06:03 Message: Logged In: YES user_id=3060 Originator: YES Berger reports the kernel is 2.6.18. Fedora Core 6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603527&group_id=5470 From noreply at sourceforge.net Wed Nov 29 23:28:08 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 14:28:08 -0800 Subject: [ python-Bugs-1605110 ] logging %(module)s reporting wrong modules Message-ID: Bugs item #1605110, was opened at 2006-11-29 01:29 Message generated for change (Settings changed) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1605110&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Mad-Marty (mad-marty) >Assigned to: Vinay Sajip (vsajip) Summary: logging %(module)s reporting wrong modules Initial Comment: I recently upgraded from python 2.4.2 to 2.4.4 and the logging seems to be working wrong now. I have a formatter which uses the %(module)s and %(filename)s and the point to the wrong file/module. I have some plugins in .py files, which mainly have one class derived from threading.Thread. Those classes logging calls will now log as 2006-11-29 10:17:50 - threading.py - threading - INFO - ... instead of 2006-11-29 10:17:50 - myplugin.py - myplugin - INFO - ... ---------------------------------------------------------------------- Comment By: Mad-Marty (mad-marty) Date: 2006-11-29 04:02 Message: Logged In: YES user_id=1269426 Originator: YES Checked again and found that the bug was introduced with Python 2.4.2. Last correctly working version is python-2.4.1.msi. ---------------------------------------------------------------------- Comment By: Mad-Marty (mad-marty) Date: 2006-11-29 01:32 Message: Logged In: YES user_id=1269426 Originator: YES Forgot to add, that is is the 2.4.4 windows package used on windows xp. ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1605110&group_id=5470 From noreply at sourceforge.net Thu Nov 30 04:20:11 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 19:20:11 -0800 Subject: [ python-Bugs-1580563 ] "make install" for Python 2.4.4 not working properly Message-ID: <200611300320.kAU3KBRn013437@sc8-sf-db2-new-b.sourceforge.net> Bugs item #1580563, was opened at 2006-10-19 07:21 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Andreas Jung (ajung) Assigned to: Nobody/Anonymous (nobody) Summary: "make install" for Python 2.4.4 not working properly Initial Comment: Running "make install" on Linux (Suse 10.1) won't terminate properly: Compiling /opt/python-2.4.4/lib/python2.4/user.py ... Compiling /opt/python-2.4.4/lib/python2.4/uu.py ... Compiling /opt/python-2.4.4/lib/python2.4/warnings.py ... Compiling /opt/python-2.4.4/lib/python2.4/wave.py ... Compiling /opt/python-2.4.4/lib/python2.4/weakref.py ... Compiling /opt/python-2.4.4/lib/python2.4/webbrowser.py ... Compiling /opt/python-2.4.4/lib/python2.4/whichdb.py ... Compiling /opt/python-2.4.4/lib/python2.4/whrandom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xdrlib.py ... Listing /opt/python-2.4.4/lib/python2.4/xml ... Compiling /opt/python-2.4.4/lib/python2.4/xml/__init__.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/dom ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/NodeFilter.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/domreg.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/expatbuilder.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/minicompat.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/minidom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/pulldom.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/dom/xmlbuilder.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/parsers ... Compiling /opt/python-2.4.4/lib/python2.4/xml/parsers/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/parsers/expat.py ... Listing /opt/python-2.4.4/lib/python2.4/xml/sax ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/__init__.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/_exceptions.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/expatreader.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/handler.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/saxutils.py ... Compiling /opt/python-2.4.4/lib/python2.4/xml/sax/xmlreader.py ... Compiling /opt/python-2.4.4/lib/python2.4/xmllib.py ... Compiling /opt/python-2.4.4/lib/python2.4/xmlrpclib.py ... Compiling /opt/python-2.4.4/lib/python2.4/zipfile.py ... make: *** [libinstall] Error 1 ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2006-11-29 19:20 Message: Logged In: YES user_id=1312539 Originator: NO 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: Martin v. L?wis (loewis) Date: 2006-11-12 13:34 Message: Logged In: YES user_id=21627 ajung: can you please report what environment settings you are using? If you have set PYTHON* in your environment, make sure to unset all these variables. ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-11 12:29 Message: Logged In: YES user_id=1642549 I created a new bug report so I could attach a file. See #1594809 ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-10 15:52 Message: Logged In: YES user_id=21627 Can you please provide a *complete* log file (i.e. terminal output) of the "make install" run? If SF rejects it because it is too large, try compressing it. ---------------------------------------------------------------------- Comment By: Evan (erflynn) Date: 2006-11-10 12:55 Message: Logged In: YES user_id=1642549 Hi, I am having exactly the same issue on Python 2.5. configure arguments have nothing special. This was on a Debian Woody system on which I have an account but not root access. Please let me know what to do in order to supply more information. ~Evan ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-10-20 00:52 Message: Logged In: YES user_id=21627 I can't reproduce this. It installs fine for me (although I try to install to /tmp/python-2.4.4, not opt), and also not on SuSE, but Debian unstable. Can you please debug through compileall, to find out whether and how exit_status gets set to a non-zero value? For that to happen, success should be set to 0 at some point. ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2006-10-19 11:00 Message: Logged In: YES user_id=11084 On both system just "configure --prefix=/opt/python-2.4.4" ---------------------------------------------------------------------- Comment By: Ronald Oussoren (ronaldoussoren) Date: 2006-10-19 10:26 Message: Logged In: YES user_id=580910 What are the configure arguments that you are using? ---------------------------------------------------------------------- Comment By: Andreas Jung (ajung) Date: 2006-10-19 07:33 Message: Logged In: YES user_id=11084 Same issue on MacOSX ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1580563&group_id=5470 From noreply at sourceforge.net Thu Nov 30 10:18:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Nov 2006 01:18:45 -0800 Subject: [ python-Bugs-1605110 ] logging %(module)s reporting wrong modules Message-ID: Bugs item #1605110, was opened at 2006-11-29 09:29 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1605110&group_id=5470 Please note that this message will contain 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: Works For Me Priority: 5 Private: No Submitted By: Pieter Zieschang (mad-marty) Assigned to: Vinay Sajip (vsajip) Summary: logging %(module)s reporting wrong modules Initial Comment: I recently upgraded from python 2.4.2 to 2.4.4 and the logging seems to be working wrong now. I have a formatter which uses the %(module)s and %(filename)s and the point to the wrong file/module. I have some plugins in .py files, which mainly have one class derived from threading.Thread. Those classes logging calls will now log as 2006-11-29 10:17:50 - threading.py - threading - INFO - ... instead of 2006-11-29 10:17:50 - myplugin.py - myplugin - INFO - ... ---------------------------------------------------------------------- >Comment By: Vinay Sajip (vsajip) Date: 2006-11-30 09:18 Message: Logged In: YES user_id=308438 Originator: NO I need more information. For example (N.B. lines may wrap, please adjust if copy/pasting the code below): #-- test.py import module import logging logging.basicConfig(level=logging.DEBUG, format="%(relativeCreated)-6d %(module)s %(filename)s %(lineno)d - %(message)s") logging.getLogger("test").debug("Test starting, about to start thread...") threads = module.start() for t in threads: t.join() logging.getLogger("test").debug("All done.") #-- test.py ends #-- module.py import logging import threading import random import time class MyThread(threading.Thread): def run(self): loops = 5 while True: logging.getLogger("module").debug("Running in thread: %s", threading.currentThread().getName()) time.sleep(random.random()) loops -= 1 if loops < 0: break class MyOtherThread(threading.Thread): def run(self): loops = 5 while True: logging.getLogger("module").debug("Running in thread: %s", threading.currentThread().getName()) time.sleep(random.random()) loops -= 1 if loops < 0: break def start(): t1 = MyThread(name="Thread One") t2 = MyOtherThread(name="Thread Two") t1.start() t2.start() return t1, t2 #-- module.py ends When I run test, I get the following output: 15 test test.py 7 - Test starting, about to start thread... 15 module module.py 11 - Running in thread: Thread One 15 module module.py 22 - Running in thread: Thread Two 327 module module.py 11 - Running in thread: Thread One 343 module module.py 22 - Running in thread: Thread Two 655 module module.py 11 - Running in thread: Thread One 780 module module.py 22 - Running in thread: Thread Two 1000 module module.py 11 - Running in thread: Thread One 1546 module module.py 22 - Running in thread: Thread Two 1890 module module.py 11 - Running in thread: Thread One 2046 module module.py 11 - Running in thread: Thread One 2218 module module.py 22 - Running in thread: Thread Two 2562 module module.py 22 - Running in thread: Thread Two 3187 test test.py 11 - All done. This is the expected output. Python version used: ActivePython 2.4.3 Build 12 (ActiveState Software Inc.) based on Python 2.4.3 (#69, Apr 11 2006, 15:32:42) [MSC v.1310 32 bit (Intel)] on win32 ---------------------------------------------------------------------- Comment By: Pieter Zieschang (mad-marty) Date: 2006-11-29 12:02 Message: Logged In: YES user_id=1269426 Originator: YES Checked again and found that the bug was introduced with Python 2.4.2. Last correctly working version is python-2.4.1.msi. ---------------------------------------------------------------------- Comment By: Pieter Zieschang (mad-marty) Date: 2006-11-29 09:32 Message: Logged In: YES user_id=1269426 Originator: YES Forgot to add, that is is the 2.4.4 windows package used on windows xp. ;-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1605110&group_id=5470 From noreply at sourceforge.net Thu Nov 30 15:46:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Nov 2006 06:46:19 -0800 Subject: [ python-Bugs-1606092 ] csv module broken for unicode Message-ID: Bugs item #1606092, was opened at 2006-11-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=1606092&group_id=5470 Please note that this 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: Open Resolution: None Priority: 5 Private: No Submitted By: JettLogic (jettlogic) Assigned to: M.-A. Lemburg (lemburg) Summary: csv module broken for unicode Initial Comment: The csv module does not accept data to write/read as anything other than ascii-or-utf-8 str, and the do-it-yourself example in the Python 2.5 Manual to write in another encoding is extremely clunky: 1) convert unicode to utf-8 2) use csv on utf-8 with cStringIO output 3) convert utf-8 to unicode 4) convert unicode to target encoding (may be utf-8...) So clunky as to be a bug - csv clearly can't handle unicode at all. The module functions are in dire need of either accepting unicode objects (letting the output stream worry about the encoding, like codecs.StreamWriter), or at the very least accepting data directly in a target encoding instead of roundabout utf-8. To read another encoding is a bit less onerous than writing: 1) wrap file to return utf-8 2) use csv, getting utf-8 output 3) convert utf-8 to unicode object Anyone willing to fix the csv module? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1606092&group_id=5470 From noreply at sourceforge.net Thu Nov 30 18:51:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Nov 2006 09:51:52 -0800 Subject: [ python-Bugs-1606233 ] readline on popen3 file returns empty string before end Message-ID: Bugs item #1606233, was opened at 2006-11-30 12: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=1606233&group_id=5470 Please note that this message will contain 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 Private: No Submitted By: Bill Wallace (wayfarer3130) Assigned to: Nobody/Anonymous (nobody) Summary: readline on popen3 file returns empty string before end Initial Comment: When readline encounters some binary data (I'm not sure which character causes this) in a stream opened with popen3, it returns the empty string indicating end of file BEFORE the file is actually finished. This causes programs to terminate early. The exact same file as a local file opened in "r" mode does not have this behaviour. The stream is created using: strm1, strm2, strm3 = popen2.popen3("cvs log") and the problem is that one of the cvs log messages I'm looking at has some garabage data in it - I think it has some unix end of line's, but I'm not sure exactly what causes this. The work-around is to readline another time to see if it returns '' again - this allows it to continue reading successfully. I can attach a portion of the file if that would help, or do an od -x on the section that causes the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1606233&group_id=5470 From noreply at sourceforge.net Thu Nov 30 21:42:52 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Nov 2006 12:42:52 -0800 Subject: [ python-Bugs-1595164 ] texinfo library documentation fails to build Message-ID: Bugs item #1595164, was opened at 2006-11-12 14:15 Message generated for change (Comment added) made by pekon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595164&group_id=5470 Please note that this 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 Private: No Submitted By: Mark Diekhans (diekhans) Assigned to: Nobody/Anonymous (nobody) Summary: texinfo library documentation fails to build Initial Comment: Attempting to build the texinfo documentation generates the error (args-out-of-range 2931944 2931946). This occurs in download of 2.5 latex doc and from trunk of svn tree. elisp stack trace attached. It would be really nice if texinfo doc was still available for download. ---------------------------------------------------------------------- Comment By: Petr Konecny (pekon) Date: 2006-11-30 15:42 Message: Logged In: YES user_id=828085 Originator: NO I believe this problem is triggered by a typo in lib/libmsilib.tex:347 \begin{classdesc}{Feature}{database, id, title, desc, display\optional{, level=1\optional{, parent\optional\{, directory\optional{, attributes=0}}}} I think it should look like this: \begin{classdesc}{Feature}{database, id, title, desc, display\optional{, level=1\optional{, parent\optional{, directory\optional{, attributes=0}}}}} With this change I am able to build python-lib.texi. However makeinfo fails: makeinfo --footnote-style end --fill-column 72 --paragraph-indent 0 --output=python-lib.info python-lib.texi python-lib.texi:30398: Unmatched }. python-lib.texi:30398: Misplaced {. python-lib.texi:36389: warning: @strong{Note...} produces a spurious cross-reference in Info; reword to avoid that. python-lib.texi:49309: Unmatched `@end'. python-lib.texi:51076: Unknown command `example>>>'. python-lib.texi:51082: Unmatched `@end'. python-lib.texi:51104: Unknown command `example>>>'. python-lib.texi:51110: Unmatched `@end'. python-lib.texi:59355: Unknown command `examplefrom'. python-lib.texi:59366: `@end' expected `table', but saw `example'. makeinfo: Removing output file `python-lib.info' due to errors; use --force to preserve. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 16:47 Message: Logged In: YES user_id=21627 Can you find out what is causing this error? If not, would you be interested in rewriting this in Python? (AFAICT, there really is no reason that this conversion is written in elisp) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595164&group_id=5470 From noreply at sourceforge.net Thu Nov 30 21:55:17 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Nov 2006 12:55:17 -0800 Subject: [ python-Bugs-1595164 ] texinfo library documentation fails to build Message-ID: Bugs item #1595164, was opened at 2006-11-12 14:15 Message generated for change (Comment added) made by pekon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595164&group_id=5470 Please note that this 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 Private: No Submitted By: Mark Diekhans (diekhans) Assigned to: Nobody/Anonymous (nobody) Summary: texinfo library documentation fails to build Initial Comment: Attempting to build the texinfo documentation generates the error (args-out-of-range 2931944 2931946). This occurs in download of 2.5 latex doc and from trunk of svn tree. elisp stack trace attached. It would be really nice if texinfo doc was still available for download. ---------------------------------------------------------------------- Comment By: Petr Konecny (pekon) Date: 2006-11-30 15:55 Message: Logged In: YES user_id=828085 Originator: NO After changing libmsilib.tex I made some manual fixes in python-lib.texi and was able to get .info files. I am attaching diff, which shows what is broken. --- python-lib.texi 2006-11-30 12:54:04.626177825 -0800 +++ python-lib.texi.fixed 2006-11-30 12:53:28.767367718 -0800 @@ -30395,7 +30395,7 @@ QName wrapper. This can be used to wrap a QName attribute value, in order to get proper namespace handling on output. @var{text_or_uri} is a string containing the QName value, -in the form @{@{}uri{@}@}local, or, if the tag argument is given, +in the form @{uri@}local, or, if the tag argument is given, the URI part of a QName. If @var{tag} is given, the first argument is interpreted as an URI, and this argument is interpreted as a local name. @@ -49305,8 +49305,6 @@ @findex EDQUOT Quota exceeded @end table -\ifx\locallinewidth\undefined\newlength@{\locallinewidth@}@end ifinfo -\setlength@{\locallinewidth@}@{\linewidth@} @node ctypes, , errno, Generic Operating System Services @section A foreign function library for Python. @@ -51073,12 +51071,14 @@ Here is the wrapping with @code{ctypes}: - at example>>> from ctypes import c_int, WINFUNCTYPE, windll + at example +>>> from ctypes import c_int, WINFUNCTYPE, windll >>> from ctypes.wintypes import HWND, LPCSTR, UINT >>> prototype = WINFUNCTYPE(c_int, HWND, LPCSTR, LPCSTR, c_uint) >>> paramflags = (1, "hwnd", 0), (1, "text", "Hi"), (1, "caption", None), (1, "flags", 0) >>> MessageBox = prototype(("MessageBoxA", windll.user32), paramflags) ->>>@end example +>>> + at end example The MessageBox foreign function can now be called in these ways: @example @@ -51101,12 +51101,14 @@ Here is the wrapping with @code{ctypes}: - at example>>> from ctypes import POINTER, WINFUNCTYPE, windll + at example +>>> from ctypes import POINTER, WINFUNCTYPE, windll >>> from ctypes.wintypes import BOOL, HWND, RECT >>> prototype = WINFUNCTYPE(BOOL, HWND, POINTER(RECT)) >>> paramflags = (1, "hwnd"), (2, "lprect") >>> GetWindowRect = prototype(("GetWindowRect", windll.user32), paramflags) ->>>@end example +>>> + at end example Functions with output parameters will automatically return the output parameter value if there is a single one, or a tuple containing the @@ -59352,7 +59354,8 @@ . Example usage: - at examplefrom wsgiref.simple_server import make_server, demo_app + at example +from wsgiref.simple_server import make_server, demo_app httpd = make_server('', 8000, demo_app) print "Serving HTTP on port 8000..." ---------------------------------------------------------------------- Comment By: Petr Konecny (pekon) Date: 2006-11-30 15:42 Message: Logged In: YES user_id=828085 Originator: NO I believe this problem is triggered by a typo in lib/libmsilib.tex:347 \begin{classdesc}{Feature}{database, id, title, desc, display\optional{, level=1\optional{, parent\optional\{, directory\optional{, attributes=0}}}} I think it should look like this: \begin{classdesc}{Feature}{database, id, title, desc, display\optional{, level=1\optional{, parent\optional{, directory\optional{, attributes=0}}}}} With this change I am able to build python-lib.texi. However makeinfo fails: makeinfo --footnote-style end --fill-column 72 --paragraph-indent 0 --output=python-lib.info python-lib.texi python-lib.texi:30398: Unmatched }. python-lib.texi:30398: Misplaced {. python-lib.texi:36389: warning: @strong{Note...} produces a spurious cross-reference in Info; reword to avoid that. python-lib.texi:49309: Unmatched `@end'. python-lib.texi:51076: Unknown command `example>>>'. python-lib.texi:51082: Unmatched `@end'. python-lib.texi:51104: Unknown command `example>>>'. python-lib.texi:51110: Unmatched `@end'. python-lib.texi:59355: Unknown command `examplefrom'. python-lib.texi:59366: `@end' expected `table', but saw `example'. makeinfo: Removing output file `python-lib.info' due to errors; use --force to preserve. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 16:47 Message: Logged In: YES user_id=21627 Can you find out what is causing this error? If not, would you be interested in rewriting this in Python? (AFAICT, there really is no reason that this conversion is written in elisp) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595164&group_id=5470 From noreply at sourceforge.net Thu Nov 30 21:59:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Nov 2006 12:59:13 -0800 Subject: [ python-Bugs-1595164 ] texinfo library documentation fails to build Message-ID: Bugs item #1595164, was opened at 2006-11-12 20:15 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595164&group_id=5470 Please note that this 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 Private: No Submitted By: Mark Diekhans (diekhans) Assigned to: Nobody/Anonymous (nobody) Summary: texinfo library documentation fails to build Initial Comment: Attempting to build the texinfo documentation generates the error (args-out-of-range 2931944 2931946). This occurs in download of 2.5 latex doc and from trunk of svn tree. elisp stack trace attached. It would be really nice if texinfo doc was still available for download. ---------------------------------------------------------------------- >Comment By: Martin v. L?wis (loewis) Date: 2006-11-30 21:59 Message: Logged In: YES user_id=21627 Originator: NO pekon, it would be quite helpful if you could resolve this. It would be best if you could check out the subversion trunk or release25-maint branch, and then provide a patch that solves it all :-) After applying your (correct) patch, I still get such an error, so I guess there are more problems in the tex source. ---------------------------------------------------------------------- Comment By: Petr Konecny (pekon) Date: 2006-11-30 21:55 Message: Logged In: YES user_id=828085 Originator: NO After changing libmsilib.tex I made some manual fixes in python-lib.texi and was able to get .info files. I am attaching diff, which shows what is broken. --- python-lib.texi 2006-11-30 12:54:04.626177825 -0800 +++ python-lib.texi.fixed 2006-11-30 12:53:28.767367718 -0800 @@ -30395,7 +30395,7 @@ QName wrapper. This can be used to wrap a QName attribute value, in order to get proper namespace handling on output. @var{text_or_uri} is a string containing the QName value, -in the form @{@{}uri{@}@}local, or, if the tag argument is given, +in the form @{uri@}local, or, if the tag argument is given, the URI part of a QName. If @var{tag} is given, the first argument is interpreted as an URI, and this argument is interpreted as a local name. @@ -49305,8 +49305,6 @@ @findex EDQUOT Quota exceeded @end table -\ifx\locallinewidth\undefined\newlength@{\locallinewidth@}@end ifinfo -\setlength@{\locallinewidth@}@{\linewidth@} @node ctypes, , errno, Generic Operating System Services @section A foreign function library for Python. @@ -51073,12 +51071,14 @@ Here is the wrapping with @code{ctypes}: - at example>>> from ctypes import c_int, WINFUNCTYPE, windll + at example +>>> from ctypes import c_int, WINFUNCTYPE, windll >>> from ctypes.wintypes import HWND, LPCSTR, UINT >>> prototype = WINFUNCTYPE(c_int, HWND, LPCSTR, LPCSTR, c_uint) >>> paramflags = (1, "hwnd", 0), (1, "text", "Hi"), (1, "caption", None), (1, "flags", 0) >>> MessageBox = prototype(("MessageBoxA", windll.user32), paramflags) ->>>@end example +>>> + at end example The MessageBox foreign function can now be called in these ways: @example @@ -51101,12 +51101,14 @@ Here is the wrapping with @code{ctypes}: - at example>>> from ctypes import POINTER, WINFUNCTYPE, windll + at example +>>> from ctypes import POINTER, WINFUNCTYPE, windll >>> from ctypes.wintypes import BOOL, HWND, RECT >>> prototype = WINFUNCTYPE(BOOL, HWND, POINTER(RECT)) >>> paramflags = (1, "hwnd"), (2, "lprect") >>> GetWindowRect = prototype(("GetWindowRect", windll.user32), paramflags) ->>>@end example +>>> + at end example Functions with output parameters will automatically return the output parameter value if there is a single one, or a tuple containing the @@ -59352,7 +59354,8 @@ . Example usage: - at examplefrom wsgiref.simple_server import make_server, demo_app + at example +from wsgiref.simple_server import make_server, demo_app httpd = make_server('', 8000, demo_app) print "Serving HTTP on port 8000..." ---------------------------------------------------------------------- Comment By: Petr Konecny (pekon) Date: 2006-11-30 21:42 Message: Logged In: YES user_id=828085 Originator: NO I believe this problem is triggered by a typo in lib/libmsilib.tex:347 \begin{classdesc}{Feature}{database, id, title, desc, display\optional{, level=1\optional{, parent\optional\{, directory\optional{, attributes=0}}}} I think it should look like this: \begin{classdesc}{Feature}{database, id, title, desc, display\optional{, level=1\optional{, parent\optional{, directory\optional{, attributes=0}}}}} With this change I am able to build python-lib.texi. However makeinfo fails: makeinfo --footnote-style end --fill-column 72 --paragraph-indent 0 --output=python-lib.info python-lib.texi python-lib.texi:30398: Unmatched }. python-lib.texi:30398: Misplaced {. python-lib.texi:36389: warning: @strong{Note...} produces a spurious cross-reference in Info; reword to avoid that. python-lib.texi:49309: Unmatched `@end'. python-lib.texi:51076: Unknown command `example>>>'. python-lib.texi:51082: Unmatched `@end'. python-lib.texi:51104: Unknown command `example>>>'. python-lib.texi:51110: Unmatched `@end'. python-lib.texi:59355: Unknown command `examplefrom'. python-lib.texi:59366: `@end' expected `table', but saw `example'. makeinfo: Removing output file `python-lib.info' due to errors; use --force to preserve. ---------------------------------------------------------------------- Comment By: Martin v. L?wis (loewis) Date: 2006-11-12 22:47 Message: Logged In: YES user_id=21627 Can you find out what is causing this error? If not, would you be interested in rewriting this in Python? (AFAICT, there really is no reason that this conversion is written in elisp) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1595164&group_id=5470 From noreply at sourceforge.net Thu Nov 30 22:14:03 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Nov 2006 13:14:03 -0800 Subject: [ python-Bugs-1599055 ] csv module does not handle '\x00' Message-ID: Bugs item #1599055, was opened at 2006-11-19 01:47 Message generated for change (Comment added) made by j_70 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: Stephen Day (shday) Assigned to: Nobody/Anonymous (nobody) Summary: csv module does not handle '\x00' Initial Comment: The following from an interactive session failed instead of just returning the '\x00': >>> r = csv.reader(['a,line,with,a,null,\x00,byte']) >>> r.next() Traceback (most recent call last): File "", line 1, in -toplevel- r.next() Error: string with NUL bytes >>> ---------------------------------------------------------------------- Comment By: j_70 (j_70) Date: 2006-11-30 21:14 Message: Logged In: YES user_id=1437039 Originator: NO Could someone post a try / except block that handles this. ---------------------------------------------------------------------- Comment By: Skip Montanaro (montanaro) Date: 2006-11-19 20:17 Message: Logged In: YES user_id=44345 Originator: NO If the device is transmitting the occasional spurious you might try wrapping your file object in a class which simply deletes any NUL bytes it encounters. ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-19 17:23 Message: Logged In: YES user_id=849994 Originator: NO The core of the csv module is coded in C, so null bytes are as always notoriously problematic when handling strings. (This is why there's a specific error message only for null bytes.) I think that the try-except is the sanest solution to this. ---------------------------------------------------------------------- Comment By: Stephen Day (shday) Date: 2006-11-19 17:08 Message: Logged In: YES user_id=948502 Originator: YES I've been using the csv module to parse data coming from a serial port of a lab instrument. Occasionally the instrument transmits a lone /x00 (maybe when the power cycles, I'm not sure). Anyhow, I'm now using a try-except statement to catch the error. I guess my answer to your question is that I think the module should handle whatever string you pass it. Is there a specific reason not to handle /x00? ---------------------------------------------------------------------- Comment By: Georg Brandl (gbrandl) Date: 2006-11-19 15:09 Message: Logged In: YES user_id=849994 Originator: NO Why do you think a CSV reader should support null bytes? CSV is a text format, not a binary one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599055&group_id=5470