[ python-Bugs-1739659 ] Interactive help raise exception while listing modules
Bugs item #1739659, was opened at 2007-06-19 15:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739659&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 3000 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: Interactive help raise exception while listing modules Initial Comment: Pydoc module shouldn't try to get slice from the dict's keys view and should use floor division where appropriate. The fix attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739659&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1739678 ] make colon optional
Feature Requests item #1739678, was opened at 2007-06-19 13:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1739678&group_id=5470 Please note that this 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: Chris (cvogtaz) Assigned to: Nobody/Anonymous (nobody) Summary: make colon optional Initial Comment: Make colon optional after class Abcd: def xyz(): if n=m: ... etc. P.S. Wonder why I did not find this FR already -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1739678&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1739679 ] add multi-line comments
Feature Requests item #1739679, was opened at 2007-06-19 13:57 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=1739679&group_id=5470 Please note that this 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: Chris (cvogtaz) Assigned to: Nobody/Anonymous (nobody) Summary: add multi-line comments Initial Comment: python lacks something like /* commentblock lalala more comment another line */ which I would like to use particularily while debugging to remove some lines of code temorarily. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1739679&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1739678 ] make colon optional
Feature Requests item #1739678, was opened at 2007-06-19 11:55 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1739678&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Chris (cvogtaz) Assigned to: Nobody/Anonymous (nobody) Summary: make colon optional Initial Comment: Make colon optional after class Abcd: def xyz(): if n=m: ... etc. P.S. Wonder why I did not find this FR already -- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 12:27 Message: Logged In: YES user_id=849994 Originator: NO This was pondered a long time ago, and usability surveys showed that the colon adds quite a lot in terms of readability, so it will stay. Marking as Rejected. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1739678&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1739659 ] Interactive help raise exception while listing modules
Bugs item #1739659, was opened at 2007-06-19 11:16 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739659&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 3000 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Dmitry Vasiliev (hdima) Assigned to: Nobody/Anonymous (nobody) Summary: Interactive help raise exception while listing modules Initial Comment: Pydoc module shouldn't try to get slice from the dict's keys view and should use floor division where appropriate. The fix attached. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 12:33 Message: Logged In: YES user_id=849994 Originator: NO Thanks for the patch, committed in rev. 56037. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739659&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1737864 ] logging.exception() does not allow empty string
Bugs item #1737864, was opened at 2007-06-15 14:50
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737864&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Dmitrii Tisnek (dimaq)
Assigned to: Vinay Sajip (vsajip)
Summary: logging.exception() does not allow empty string
Initial Comment:
Due to the following code, logging.exception("") does not work. I suggest
replacing s[-1]=="\n" with s.endswith("\n").
logging/__init__.py:formatException():
--snip--
if s[-1] == "\n":
s = s[:-1]
return s
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-06-19 12:36
Message:
Logged In: YES
user_id=849994
Originator: NO
Fixed in rev. 56038, 56039 (2.5).
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-06-15 16:39
Message:
Logged In: YES
user_id=849994
Originator: NO
Sounds reasonable.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737864&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1739115 ] shutil.rmtree's error message is confusing
Bugs item #1739115, was opened at 2007-06-18 14:41 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739115&group_id=5470 Please note that this 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: Bj�rn Lindqvist (sonderblade) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.rmtree's error message is confusing Initial Comment: If you run shutil.rmtree(something) on Windows where something is file and not a directory, you get the following exception: Traceback (most recent call last): File "", line 1, in File "C:\Python25\Lib\shutil.py", line 161, in rmtree onerror(os.listdir, path, sys.exc_info()) File "C:\Python25\Lib\shutil.py", line 159, in rmtree names = os.listdir(path) WindowsError: [Error 22] The directory name is invalid: 'foobar/*.*' The error message is pretty confusing and it shouldn't be to hard to fix it. Plus, if it shouldn't be possible to remove files with shutil.rmtree(), then the docs should say so. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 12:38 Message: Logged In: YES user_id=849994 Originator: NO Updated the docs in rev. 56040, 56041 (2.5). IMO the error message is clear enough now if you read the docs. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739115&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1738441 ] shutil.move doesn't work when only case changes
Bugs item #1738441, was opened at 2007-06-16 18:25 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738441&group_id=5470 Please note that this message will contain a full 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: Gabriel Gambetta (ggambett) Assigned to: Nobody/Anonymous (nobody) Summary: shutil.move doesn't work when only case changes Initial Comment: shutil.move() appears to fail silently when the source and destination filenames only differ in case (ie "SomeFile" and "Somefile"). This is with python 2.4.3-18.fc6, on a case-sensitive filesystem (ext3), so this rename *is* meaningful. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 12:40 Message: Logged In: YES user_id=849994 Originator: NO This is quite strange. Gabriel, could you try to use another Python version provided by Fedora, or even a self-compiled one? -- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2007-06-17 05:08 Message: Logged In: YES user_id=942711 Originator: NO I guess, this should be very much python 2.4.3-18.fc6 specific. While I have python 2.3.4, python 2.5, python 2.6a0. I am unable to reproduce this defect. Having said that, help(shutil.move) mentions about the various issues of moving the implementation glosses over. Please provide some more details or anyone with python 2.4.3-18 should be able to verify it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738441&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1738559 ] Python-2.5.1.tar.bz2 build failed at Centos-4.5 server
Bugs item #1738559, was opened at 2007-06-17 07:29 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738559&group_id=5470 Please note that this 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: shuvo (shuvo1470) Assigned to: Nobody/Anonymous (nobody) Summary: Python-2.5.1.tar.bz2 build failed at Centos-4.5 server Initial Comment: I tried to build Python-2.5.1.tar.bz2 at my Centos-4.5 server but unable to build it. there is the error i am getting File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ChipViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/TypeinViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/pyColorChooser.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/Main.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/TextViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ColorDB.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/StripViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/DetailsViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/ListViewer.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/PyncheWidget.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/Switchboard.pyo File not found: /var/tmp/python2.5-2.5.1-root/usr/lib/python2.5/Tools/pynche/__init__.pyo -- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 12:41 Message: Logged In: YES user_id=849994 Originator: NO Are these the first error messages in the build process? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1738559&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1737127 ] re.findall hangs python completely
Bugs item #1737127, was opened at 2007-06-14 12:05 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737127&group_id=5470 Please note that this 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: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Arno Bakker (abakker) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re.findall hangs python completely Initial Comment: Running a re.findall() on 40 KB of HTML appears to hang python completely. It hogs the CPU (perhaps not unexpected) but other python threads do not continue and pressing Ctrl-C does not trigger a KeyboardInterrupt. Only a SIGQUIT (Ctrl-\) can kill it. Attached is a small script to illustrate the problem, and the data file that causes it to hang. Using 40 KB of random data does let it get past the first findall. It creates a Thread that should printout hashes continuously, however, as soon as the MainThread hits the findall the printing stops. Occurs on Python-2.4.4 (direct from www.python.org) and 2.5.1 (2.5.1-0ubuntu1 from Feisty) -- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 12:44 Message: Logged In: YES user_id=849994 Originator: NO This is quite normal for regular expressions with a lot of backtracking permutations to try, and a big string to search in. You should try to optimize your REs -- wrt. the threads, re doesn't release the GIL while searching, that's another bug report. -- Comment By: Gregory Smith (gregsmith) Date: 2007-06-18 17:23 Message: Logged In: YES user_id=292741 Originator: NO First off, don't expect other threads to run during re execution. Multi-threading in python is mainly to allow one thread to run while the others are waiting for I/O or doing a time.sleep() or something specific like that. Switching between runnable threads only occurs in interpreter loop. There may exceptions to allow switching during some really long core operations (a mutex needs to be released and taken again) but it has to be done under certain conditions so that threads won't mess each other's data up. So, on to the r.e.: first, try changing all the .*? to just .* -- the ? is redundant and may be increasing the runtime by expanding the number of permutations that are being tried. But I think your real trouble is all of these : img src=\"(.*?)\" This allows the second " to match with anything at all between, including any number of quoted strings. Your combination of several of these may be causing the RE engine to spend a huge amount of time looking at many different combinations for the first few .*?, all of which fail by the time you get to the last one. Try img src=\"([^"]*)\" instead; this will only match the pair of " with no " in between. Likewise, in .*?> the .* will match any number of '>' chars if this is needed to make the whole thing match, which is probably not what you want. You might get it to work just by turning off 'greedy' matching for '*'. -- Comment By: Arno Bakker (abakker) Date: 2007-06-14 12:06 Message: Logged In: YES user_id=216477 Originator: YES File Added: page.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737127&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1737127 ] re.findall hangs python completely
Bugs item #1737127, was opened at 2007-06-14 14:05 Message generated for change (Comment added) made by abakker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737127&group_id=5470 Please note that this 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: None >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Arno Bakker (abakker) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re.findall hangs python completely Initial Comment: Running a re.findall() on 40 KB of HTML appears to hang python completely. It hogs the CPU (perhaps not unexpected) but other python threads do not continue and pressing Ctrl-C does not trigger a KeyboardInterrupt. Only a SIGQUIT (Ctrl-\) can kill it. Attached is a small script to illustrate the problem, and the data file that causes it to hang. Using 40 KB of random data does let it get past the first findall. It creates a Thread that should printout hashes continuously, however, as soon as the MainThread hits the findall the printing stops. Occurs on Python-2.4.4 (direct from www.python.org) and 2.5.1 (2.5.1-0ubuntu1 from Feisty) -- >Comment By: Arno Bakker (abakker) Date: 2007-06-19 16:03 Message: Logged In: YES user_id=216477 Originator: YES Is that GIL & searching problem reported separately somewhere, otherwise I'm hereby submitting that bug ;o) -- Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 14:44 Message: Logged In: YES user_id=849994 Originator: NO This is quite normal for regular expressions with a lot of backtracking permutations to try, and a big string to search in. You should try to optimize your REs -- wrt. the threads, re doesn't release the GIL while searching, that's another bug report. -- Comment By: Gregory Smith (gregsmith) Date: 2007-06-18 19:23 Message: Logged In: YES user_id=292741 Originator: NO First off, don't expect other threads to run during re execution. Multi-threading in python is mainly to allow one thread to run while the others are waiting for I/O or doing a time.sleep() or something specific like that. Switching between runnable threads only occurs in interpreter loop. There may exceptions to allow switching during some really long core operations (a mutex needs to be released and taken again) but it has to be done under certain conditions so that threads won't mess each other's data up. So, on to the r.e.: first, try changing all the .*? to just .* -- the ? is redundant and may be increasing the runtime by expanding the number of permutations that are being tried. But I think your real trouble is all of these : img src=\"(.*?)\" This allows the second " to match with anything at all between, including any number of quoted strings. Your combination of several of these may be causing the RE engine to spend a huge amount of time looking at many different combinations for the first few .*?, all of which fail by the time you get to the last one. Try img src=\"([^"]*)\" instead; this will only match the pair of " with no " in between. Likewise, in .*?> the .* will match any number of '>' chars if this is needed to make the whole thing match, which is probably not what you want. You might get it to work just by turning off 'greedy' matching for '*'. -- Comment By: Arno Bakker (abakker) Date: 2007-06-14 14:06 Message: Logged In: YES user_id=216477 Originator: YES File Added: page.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737127&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1737127 ] re.findall hangs python completely
Bugs item #1737127, was opened at 2007-06-14 12:05 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737127&group_id=5470 Please note that this 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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Arno Bakker (abakker) Assigned to: Gustavo Niemeyer (niemeyer) Summary: re.findall hangs python completely Initial Comment: Running a re.findall() on 40 KB of HTML appears to hang python completely. It hogs the CPU (perhaps not unexpected) but other python threads do not continue and pressing Ctrl-C does not trigger a KeyboardInterrupt. Only a SIGQUIT (Ctrl-\) can kill it. Attached is a small script to illustrate the problem, and the data file that causes it to hang. Using 40 KB of random data does let it get past the first findall. It creates a Thread that should printout hashes continuously, however, as soon as the MainThread hits the findall the printing stops. Occurs on Python-2.4.4 (direct from www.python.org) and 2.5.1 (2.5.1-0ubuntu1 from Feisty) -- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 15:29 Message: Logged In: YES user_id=849994 Originator: NO It's a feature request, not a bug, but it is submitted, yes :) -- Comment By: Arno Bakker (abakker) Date: 2007-06-19 14:03 Message: Logged In: YES user_id=216477 Originator: YES Is that GIL & searching problem reported separately somewhere, otherwise I'm hereby submitting that bug ;o) -- Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 12:44 Message: Logged In: YES user_id=849994 Originator: NO This is quite normal for regular expressions with a lot of backtracking permutations to try, and a big string to search in. You should try to optimize your REs -- wrt. the threads, re doesn't release the GIL while searching, that's another bug report. -- Comment By: Gregory Smith (gregsmith) Date: 2007-06-18 17:23 Message: Logged In: YES user_id=292741 Originator: NO First off, don't expect other threads to run during re execution. Multi-threading in python is mainly to allow one thread to run while the others are waiting for I/O or doing a time.sleep() or something specific like that. Switching between runnable threads only occurs in interpreter loop. There may exceptions to allow switching during some really long core operations (a mutex needs to be released and taken again) but it has to be done under certain conditions so that threads won't mess each other's data up. So, on to the r.e.: first, try changing all the .*? to just .* -- the ? is redundant and may be increasing the runtime by expanding the number of permutations that are being tried. But I think your real trouble is all of these : img src=\"(.*?)\" This allows the second " to match with anything at all between, including any number of quoted strings. Your combination of several of these may be causing the RE engine to spend a huge amount of time looking at many different combinations for the first few .*?, all of which fail by the time you get to the last one. Try img src=\"([^"]*)\" instead; this will only match the pair of " with no " in between. Likewise, in .*?> the .* will match any number of '>' chars if this is needed to make the whole thing match, which is probably not what you want. You might get it to work just by turning off 'greedy' matching for '*'. -- Comment By: Arno Bakker (abakker) Date: 2007-06-14 12:06 Message: Logged In: YES user_id=216477 Originator: YES File Added: page.html -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1737127&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1739679 ] add multi-line comments
Feature Requests item #1739679, was opened at 2007-06-19 11:57 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1739679&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Chris (cvogtaz) Assigned to: Nobody/Anonymous (nobody) Summary: add multi-line comments Initial Comment: python lacks something like /* commentblock lalala more comment another line */ which I would like to use particularily while debugging to remove some lines of code temorarily. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-06-19 15:31 Message: Logged In: YES user_id=849994 Originator: NO For that, you should use a decent editor that can comment out multiple lines of code at once. Alternatively, if you don't have such an editor, you can enclose the code in triple-quoted strings or put an "if 0:" around it. In any way, Guido pronounced this isn't going to happen. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1739679&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1739842 ] xmlrpclib can no longer marshal Fault objects
Bugs item #1739842, was opened at 2007-06-19 12: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=1739842&group_id=5470 Please note that this message will contain a full 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 Bonnet (mbonnet) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib can no longer marshal Fault objects Initial Comment: xmlrpclib attempts to marshal class instances by registering the dump_instance() method as the marshaller for the type. This is how marshalling of Fault objects contained in a tuple (for example, one result in a multicall) is handled. This worked for Fault objects in python2.4 and earlier because they were old-style classes, and their type was always . In python2.5, Exception (and thus Fault, which inherits from it) moved from an old-style class to a new-style class (inheriting from object). This means that rather than type(faultinstance) returning , it returns . This results in xmlrpclib.Marshaller.__dump() throwing TypeError when it encounters a Fault (or any other new-style class). This is a regression from python2.4 and earlier, and is particularly problematic for applications that expect to be able to marshal Fault instances. I've attached a simple patch which allows Fault objects (and all other new-style classes) to be marshalled as structs, the same way Fault objects and old-style classes were in python2.4 and earlier. This fixes the regression caused by the change in the Exception inheritance hierarchy. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1739842&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1720705 ] thread + import => crashes?
Bugs item #1720705, was opened at 2007-05-17 13:08 Message generated for change (Comment added) made by andyshorts You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1720705&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.5 Status: Open Resolution: None Priority: 6 Private: No Submitted By: Hirokazu Yamamoto (ocean-city) Assigned to: Nobody/Anonymous (nobody) Summary: thread + import => crashes? Initial Comment: I got some experience of crash on Tkinter, so I minimized triger code. (I'll attach it as 'bug.py') Same error happens on released python 2.5.1 binary, trunk built with VC6, and release25-maint built with VC6. (Not every time this error occurs, but frequently) # Here is error message. S:\python\tkinter>bug.py Traceback (most recent call last): File "S:\python\tkinter\bug.py", line 13, in raise RuntimeError() RuntimeError Fatal Python error: PyImport_GetModuleDict: no module dictionary! This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. # Here is stack trace. (Win2000SP4 + VC6) NTDLL! 77f9193c() PyImport_GetModuleDict() line 361 + 10 bytes import_submodule(_object * 0x1e3148b8 __Py_NoneStruct, char * 0x013fe440, char * 0x013fe440) line 2357 + 5 bytes load_next(_object * 0x1e3148b8 __Py_NoneStruct, _object * 0x1e3148b8 __Py_NoneStruct, char * * 0x013fe554, char * 0x013fe440, int * 0x013fe43c) line 2216 + 17 bytes import_module_level(char * 0x, _object * 0x008e6620, _object * 0x1e3148b8 __Py_NoneStruct, _object * 0x1e3148b8 __Py_NoneStruct, int -1) line 1997 + 35 bytes PyImport_ImportModuleLevel(char * 0x009408cc, _object * 0x008e6620, _object * 0x1e3148b8 __Py_NoneStruct, _object * 0x1e3148b8 __Py_NoneStruct, int -1) line 2068 + 25 bytes builtin___import__(_object * 0x, _object * 0x00b0aaa0, _object * 0x) line 48 + 25 bytes PyCFunction_Call(_object * 0x008cf478, _object * 0x00b0aaa0, _object * 0x) line 77 + 15 bytes PyObject_Call(_object * 0x008cf478, _object * 0x00b0aaa0, _object * 0x) line 1860 + 15 bytes PyEval_CallObjectWithKeywords(_object * 0x008cf478, _object * 0x00b0aaa0, _object * 0x) line 3434 PyEval_EvalFrameEx(_frame * 0x00a5d3e8, int 107) line 2065 fast_function(_object * 0x, _object * * * 0x013fef00, int 1, int 1, int 10152296) line 3651 call_function(_object * * * 0x013fef00, int 0) line 3585 + 16 bytes PyEval_EvalFrameEx(_frame * 0x00a706b8, int 131) line 2269 PyEval_EvalCodeEx(PyCodeObject * 0x009e80e8, _object * 0x00a706b8, _object * 0x0002, _object * * 0x00ac86a0, int 2, _object * * 0x00ac86a8, int 0, _object * * 0x00a1ccfc, int 1, _object * 0x) line 2831 + 11 bytes fast_function(_object * 0x0001, _object * * * 0x013ff418, int 2, int 2, int 0) line 3663 + 53 bytes call_function(_object * * * 0x013ff418, int 0) line 3585 + 16 bytes PyEval_EvalFrameEx(_frame * 0x00ac8528, int 131) line 2269 PyEval_EvalCodeEx(PyCodeObject * 0x009e4c88, _object * 0x00ac8528, _object * 0x0002, _object * * 0x00a5b590, int 2, _object * * 0x00a5b598, int 0, _object * * 0x00a1cc1c, int 1, _object * 0x) line 2831 + 11 bytes fast_function(_object * 0x0001, _object * * * 0x013ff930, int 2, int 2, int 0) line 3663 + 53 bytes call_function(_object * * * 0x013ff930, int 0) line 3585 + 16 bytes PyEval_EvalFrameEx(_frame * 0x00a5b440, int 131) line 2269 PyEval_EvalCodeEx(PyCodeObject * 0x009e44a8, _object * 0x00a5b440, _object * 0x0001, _object * * 0x00a5b224, int 1, _object * * 0x00a5b228, int 0, _object * * 0x00a1e9cc, int 2, _object * 0x) line 2831 + 11 bytes fast_function(_object * 0x0002, _object * * * 0x013ffe48, int 1, int 1, int 0) line 3663 + 53 bytes call_function(_object * * * 0x013ffe48, int 0) line 3585 + 16 bytes PyEval_EvalFrameEx(_frame * 0x00a5b0e0, int 131) line 2269 PyEval_EvalCodeEx(PyCodeObject * 0x009d5ce8, _object * 0x00a5b0e0, _object * 0x, _object * * 0x008c104c, int 0, _object * * 0x, int 0, _object * * 0x, int 0, _object * 0x) line 2831 + 11 bytes function_call(_object * 0x00a2b140, _object * 0x008c1038, _object * 0x) line 522 + 64 bytes PyObject_Call(_object * 0x00a2b140, _object * 0x008c1038, _object * 0x) line 1860 + 15 bytes PyEval_CallObjectWithKeywords(_object * 0x00a2b140, _object * 0x008c1038, _object * 0x) line 3434 t_bootstrap(void * 0x008c8508) line 425 + 26 bytes bootstrap(void * 0x0022f8cc) line 179 + 7 bytes _threadstart(void * 0x009bff78) line 187 + 13 bytes KERNEL32! 77e5b396() -- Comment By: AndyShorts (andyshorts) Date: 2007-06-19 23:40 Message: Logged In: YES user_id=1563697 Originator: NO I have had a look
