[issue3112] implement PEP 3134 exception reporting

2008-07-15 Thread Benjamin Peterson
Benjamin Peterson [EMAIL PROTECTED] added the comment: Antonine, do you have a patch address the review comments? -- assignee: - benjamin.peterson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3112

[issue3112] implement PEP 3134 exception reporting

2008-07-15 Thread Antoine Pitrou
Antoine Pitrou [EMAIL PROTECTED] added the comment: Antonine, do you have a patch address the review comments? Yes, although I've forgotten to upload it here - you will find it at http://codereview.appspot.com/2448 PS: it is Antoine not Antonine :) ___

[issue3112] implement PEP 3134 exception reporting

2008-07-15 Thread Benjamin Peterson
Benjamin Peterson [EMAIL PROTECTED] added the comment: Sorry, Antoine! The patch is in with r64965. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3112

[issue3112] implement PEP 3134 exception reporting

2008-07-13 Thread Antoine Pitrou
Antoine Pitrou [EMAIL PROTECTED] added the comment: Here is a new patch incorporating Amaury's better indentation fix for tracebacks. It should be ready for consumption (all the tests pass). And for the code review junkies: http://codereview.appspot.com/2448 Added file:

[issue3112] implement PEP 3134 exception reporting

2008-07-11 Thread Amaury Forgeot d'Arc
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: I think there is a problem when the source file cannot be opened (a .pyc without its .py): the four spaces are printed, but not the line, and the following level is not properly indented. See issue3342 for a competing patch that corrects

[issue3112] implement PEP 3134 exception reporting

2008-07-11 Thread Antoine Pitrou
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le vendredi 11 juillet 2008 à 12:12 +, Amaury Forgeot d'Arc a écrit : I think there is a problem when the source file cannot be opened (a .pyc without its .py): the four spaces are printed, but not the line, and the following level is

[issue3112] implement PEP 3134 exception reporting

2008-07-11 Thread Amaury Forgeot d'Arc
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment: I committed r64881, which invalidates your patch a bit :-| BTW, I don't like your comment Can't be bothered to check all those PyFile_WriteString() calls. In general, it is not a good idea to execute python code with an exception set,

[issue3112] implement PEP 3134 exception reporting

2008-07-11 Thread Antoine Pitrou
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le vendredi 11 juillet 2008 à 22:18 +, Amaury Forgeot d'Arc a écrit : I committed r64881, which invalidates your patch a bit :-| Apparently you committed in trunk rather than py3k? Could you svnmerge into py3k as well? Then it should be

[issue3112] implement PEP 3134 exception reporting

2008-06-27 Thread Antoine Pitrou
Antoine Pitrou [EMAIL PROTECTED] added the comment: Here is the final patch. Features: - cleanup of internal APIs - standardize traceback indentation (source lines are prefixed with 4 spaces) - break cycles along the context chain (a synthetic benchmark with a 6-level deep context chain shows a

[issue3112] implement PEP 3134 exception reporting

2008-06-23 Thread Adam Olsen
Adam Olsen [EMAIL PROTECTED] added the comment: On Sun, Jun 22, 2008 at 2:56 PM, Antoine Pitrou [EMAIL PROTECTED] wrote: Le dimanche 22 juin 2008 à 20:40 +, Adam Olsen a écrit : Passing in e.args is probably sufficient. I think it's very optimistic :-) Some exception objects can hold

[issue3112] implement PEP 3134 exception reporting

2008-06-23 Thread Antoine Pitrou
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le lundi 23 juin 2008 à 06:16 +, Adam Olsen a écrit : Failure doesn't have an args tuple and doesn't subclass Exception (or BaseException) - it already needs modification in 3.0. It's heaped full of complexity and implementation

[issue3112] implement PEP 3134 exception reporting

2008-06-22 Thread Adam Olsen
Adam Olsen [EMAIL PROTECTED] added the comment: * cause/context cycles should be avoided. Naive traceback printing could become confused, and I can't think of any accidental way to provoke it (besides the problem mentioned here.) * I suspect PyErr_Display handled string exceptions in 2.x, and

[issue3112] implement PEP 3134 exception reporting

2008-06-22 Thread Antoine Pitrou
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le dimanche 22 juin 2008 à 07:04 +, Adam Olsen a écrit : Adam Olsen [EMAIL PROTECTED] added the comment: * cause/context cycles should be avoided. Naive traceback printing could become confused, and I can't think of any accidental way

[issue3112] implement PEP 3134 exception reporting

2008-06-22 Thread Adam Olsen
Adam Olsen [EMAIL PROTECTED] added the comment: On Sun, Jun 22, 2008 at 8:07 AM, Antoine Pitrou [EMAIL PROTECTED] wrote: You mean they should be detected when the exception is set? I was afraid that it may make exception raising slower. Reporting is not performance sensitive in comparison to

[issue3112] implement PEP 3134 exception reporting

2008-06-22 Thread Adam Olsen
Adam Olsen [EMAIL PROTECTED] added the comment: On Sun, Jun 22, 2008 at 1:04 PM, Antoine Pitrou [EMAIL PROTECTED] wrote: Antoine Pitrou [EMAIL PROTECTED] added the comment: Le dimanche 22 juin 2008 à 17:17 +, Adam Olsen a écrit : I meant only that trivial cycles should be detected.

[issue3112] implement PEP 3134 exception reporting

2008-06-22 Thread Antoine Pitrou
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le dimanche 22 juin 2008 à 19:23 +, Adam Olsen a écrit : For this behaviour, this is the most natural way to write it. Conceptually, there shouldn't be a cycle I agree your example is not far-fetched. How about avoiding cycles for

[issue3112] implement PEP 3134 exception reporting

2008-06-22 Thread Adam Olsen
Adam Olsen [EMAIL PROTECTED] added the comment: On Sun, Jun 22, 2008 at 1:48 PM, Antoine Pitrou [EMAIL PROTECTED] wrote: Antoine Pitrou [EMAIL PROTECTED] added the comment: Le dimanche 22 juin 2008 à 19:23 +, Adam Olsen a écrit : For this behaviour, this is the most natural way to write

[issue3112] implement PEP 3134 exception reporting

2008-06-22 Thread Antoine Pitrou
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le dimanche 22 juin 2008 à 19:57 +, Adam Olsen a écrit : That's still O(n). I'm not so easily convinced it's cheap enough. O(n) when n will almost never be greater than 5 (and very often equal to 1 or 2), and when the unit is the cost of

[issue3112] implement PEP 3134 exception reporting

2008-06-22 Thread Adam Olsen
Adam Olsen [EMAIL PROTECTED] added the comment: On Sun, Jun 22, 2008 at 2:20 PM, Antoine Pitrou [EMAIL PROTECTED] wrote: Antoine Pitrou [EMAIL PROTECTED] added the comment: Le dimanche 22 juin 2008 à 19:57 +, Adam Olsen a écrit : That's still O(n). I'm not so easily convinced it's

[issue3112] implement PEP 3134 exception reporting

2008-06-22 Thread Antoine Pitrou
Antoine Pitrou [EMAIL PROTECTED] added the comment: Le dimanche 22 juin 2008 à 20:40 +, Adam Olsen a écrit : How do you duplicate an instance of an user-defined exception? Using an equivalent of copy.deepcopy()? It will probably end up much more expensive than the above-mentioned O(n)

[issue3112] implement PEP 3134 exception reporting

2008-06-19 Thread Antoine Pitrou
Antoine Pitrou [EMAIL PROTECTED] added the comment: Yet another question. There is a slight discrepancy between tracebacks generated by the builtin-reporting and tracebacks generated by traceback.py. With built-in reporting: Traceback (most recent call last): File stdin, line 1, in module

[issue3112] implement PEP 3134 exception reporting

2008-06-18 Thread Antoine Pitrou
Changes by Antoine Pitrou [EMAIL PROTECTED]: -- nosy: +gvanrossum ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3112 ___ ___ Python-bugs-list mailing

[issue3112] implement PEP 3134 exception reporting

2008-06-18 Thread Antoine Pitrou
Antoine Pitrou [EMAIL PROTECTED] added the comment: Does anyone know why there is the following test in pythonrun.c: http://hg.pitrou.net/public/py3k/py3k/file/c143699d8dee/Python/pythonrun.c#l1346 Can PyErr_Display be called with something else than a PyException instance?

[issue3112] implement PEP 3134 exception reporting

2008-06-18 Thread Antoine Pitrou
Antoine Pitrou [EMAIL PROTECTED] added the comment: Two other questions: 1) Should I expose a PyErr_DisplaySingle API to display an exception without chaining? 2) Should PyErr_Display return an integer value (0: success, -1: failure) rather than void as it currently does?

[issue3112] implement PEP 3134 exception reporting

2008-06-18 Thread Antoine Pitrou
Antoine Pitrou [EMAIL PROTECTED] added the comment: Here is a draft patch for those who want to take a look. (it works but the final cleanup is waiting for the API decisions mentioned above) -- keywords: +patch Added file: http://bugs.python.org/file10656/exc_reporting.patch

[issue3112] implement PEP 3134 exception reporting

2008-06-14 Thread Benjamin Peterson
New submission from Benjamin Peterson [EMAIL PROTECTED]: Traceback reporting needs to be altered to support exception chaining as per PEP 3134. -- components: Interpreter Core messages: 68214 nosy: benjamin.peterson priority: critical severity: normal status: open title: implement PEP

[issue3112] implement PEP 3134 exception reporting

2008-06-14 Thread Benjamin Peterson
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- versions: +Python 3.0 -Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3112 ___ ___

[issue3112] implement PEP 3134 exception reporting

2008-06-14 Thread Antoine Pitrou
Changes by Antoine Pitrou [EMAIL PROTECTED]: -- nosy: +pitrou ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3112 ___ ___ Python-bugs-list mailing list

[issue3112] implement PEP 3134 exception reporting

2008-06-14 Thread Antoine Pitrou
Antoine Pitrou [EMAIL PROTECTED] added the comment: Thinking about this, I realized that an exception can become its own context if it is explicitly re-raised in its except handler (with raise variable, not bare raise). Not a critical bug, but it should be fixed in order to avoid delayed garbage