Martin Panter added the comment:
Robert: in issue17911-2.patch (and the eventual commit) you added a check for
value == 'None' in _format_final_exc_line(). Why was this necessary? I think it
is the cause of my Issue 27348 regression:
>>> traceback.format_exception(Exception, Exception("One"),
Robert Collins added the comment:
Regression fixed AFAICT, please re-open if not.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
___
Robert Collins added the comment:
Looking at the regression now.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
___
___
Python-bugs-list
Terry J. Reedy added the comment:
Idle is partially disabled in a2 (#23633), with symptoms similar to that of the
first example in msg237230. Trivial test: open Idle Shell, enter '1/0'. If
this is not fixed before .a3, I think it should be reverted until it is.
--
nosy: +terry.reedy
Changes by Terry J. Reedy tjre...@udel.edu:
--
Removed message: http://bugs.python.org/msg237840
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
___
Terry J. Reedy added the comment:
(correct new issue #) Idle is partially disabled in a2 (#23631), with symptoms
similar to that of the first example in msg237230. Trivial test: open Idle
Shell, enter '1/0'. If this is not fixed before .a3, I think it should be
reverted until it is.
Roundup Robot added the comment:
New changeset 648b35f22b91 by Berker Peksag in branch 'default':
Issue #17911: Tweak traceback documentation.
https://hg.python.org/cpython/rev/648b35f22b91
--
___
Python tracker rep...@bugs.python.org
Robert Collins added the comment:
Ok, cgitb - its passing a string instead of an exception type into
format_exception - something that was never supported - it only works by
accident AFAICT, because the old format code was ignoring the etype - it was
deriving the type from the value. Thats
Ned Deily added the comment:
Much better, thanks!
--
priority: critical - normal
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
___
___
Roundup Robot added the comment:
New changeset 7cea10917f40 by Robert Collins in branch 'default':
Fix brownbag in issue 17911 commit
https://hg.python.org/cpython/rev/7cea10917f40
--
___
Python tracker rep...@bugs.python.org
Robert Collins added the comment:
Thats really strange, I did a ./python -m test run before committing - the
brown bag was due to me running with the patch for 22936 also applied. Looking
into the failures reported now.
--
___
Python tracker
Robert Collins added the comment:
Fixes for buildbots.
--
Added file: http://bugs.python.org/file38335/issue-19711-8.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
___
STINNER Victor added the comment:
There are failures on buildbot.
http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.x/builds/5651/steps/test/logs/stdio
http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/5783/steps/test/logs/stdio
Robert Collins added the comment:
Also apologies - ned told me on IRC that python -m test -uall is needed, not
just -m test. Doh.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
___
Robert Collins added the comment:
code module is using a _function from within the traceback module to filter out
a frame - we can do that with the new interface easily (it filters the first
tem).
--
___
Python tracker rep...@bugs.python.org
Robert Collins added the comment:
The decimal failure is due to _format_final_exc_line now filtering out 'None'
as well, because the string captured values of objects leads to None - 'None'
before we do rendering.
I think in this case its reasonable to change the behaviour (since None itself
Roundup Robot added the comment:
New changeset 73afda5a4e4c by Robert Collins in branch 'default':
Issue #17911: traceback module overhaul
https://hg.python.org/cpython/rev/73afda5a4e4c
--
nosy: +python-dev
___
Python tracker rep...@bugs.python.org
Ned Deily added the comment:
With 7cea10917f40 applied, multiple tests are now failing on most buildbots.
For example, on OS X 10.10, test_cgitb test_code_module test_decimal:
test_blanks (test.test_cgitb.TestCgitb) ... ok
test_fonts (test.test_cgitb.TestCgitb) ... ok
test_html
Robert Collins added the comment:
Ok, all changes applied, lets see how this looks to folk.
--
Added file: http://bugs.python.org/file38324/issue17911-5.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
Changes by Robert Collins robe...@robertcollins.net:
Added file: http://bugs.python.org/file38325/issue17911-6.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
___
Robert Collins added the comment:
@Mahmoud thanks! I had a quick look and the structural approach we've taken is
a bit different. What do you think of the current patch here
(issue17911-4.patch) ?
--
___
Python tracker rep...@bugs.python.org
Mahmoud Hashemi added the comment:
Hey all, great to see this being worked on so diligently for so long. Having
worked in this area for a while (at home and at PayPal), we've got a few
learnings to share:
1) linecache is textbook not-threadsafe. For example,
Robert Collins added the comment:
I'm idealogically opposed to polymorphic interpretation of args :)
Antoine, will you be ok with one __init__ and one classmethod?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
Robert Collins added the comment:
Sorry xonatius I wasn't clear: AFAICT your patch is going to require changes to
the traceback tests, and this issue is changing the implementation
substantially: I was suggesting that you make sure your patch applies on top of
this issue, not that you merge
Robert Collins added the comment:
Nick, Antoine - I'm now stuck between you. Options going forward:
- I can JFDI realising you won't both be happy :)
- you two can reach consensus!
I could cripple __init__ by switching to __new__, but I think thats massive
overcomplication and not needed.
Nick Coghlan added the comment:
Escalating to python-dev for API design feedback is the usual path forward
if we reach an impasse in the tracker comments.
I'll make one more attempt at persuading Antoine here though: the fact that
we're being tempted to add do not use this API the way you would
Antoine Pitrou added the comment:
You can also switch back to a single constructor, taking either an
exception instance or an exception triple. That way everyone is happy -
except perhaps if you are ideologically opposed to polymorphic
signatures :-)
Switching to python-dev would probably be
Daniil Bondarev added the comment:
As suggested adding patch from http://bugs.python.org/issue2786 which prints
qualnames in function call exceptions.
e.g:
class A:
... def __init__(self):
... pass
A(1)
Traceback (most recent call last):
File stdin, line 1, in module
Nick Coghlan added the comment:
It's genuinely user hostile, as the from_exc_tuple version is entirely
redundant, and folks using pydoc to discover the API won't know they
shouldn't use the constructor directly.
That means both forms will get used, but only one will be documented. When
people
Antoine Pitrou added the comment:
Le 06/02/2015 09:34, Nick Coghlan a écrit :
It's genuinely user hostile, as the from_exc_tuple version is entirely
redundant, and folks using pydoc to discover the API won't know they
shouldn't use the constructor directly.
Using pydoc isn't generally a
Nick Coghlan added the comment:
dir() will get me TracebackException as a name,
help(traceback.TracebackException) will get me its signature. IDEs with
autocomplete and signature tooltips will do the same.
There is nothing in those usage sequences to say don't use __init__, use this
Antoine Pitrou added the comment:
I just posted some review comments.
I also realized that it posted some older comments that I hadn't submitted
before... some of them may be obsolete, sorry :-/
--
___
Python tracker rep...@bugs.python.org
Nick Coghlan added the comment:
I think in this case, the fact that it's easier to decompose an exception
into the corresponding triple rather than vice-versa, together with the
fact that other exception state manipulation APIs like exc_info() and
__exit__() methods work with triples, means it
Antoine Pitrou added the comment:
The solution of having two constructor classmethods actually seems nice
and symmetric to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
___
Nick Coghlan added the comment:
+1 for having the base __init__ API be the exception triple and then a
TracebackException.from_exception() class method as an alternate constructor.
However, the redundancy between TracebackException.__init__() and
TracebackException.from_exc_tuple() feels very
Robert Collins added the comment:
I can certainly do that; I was aiming to make it fair I guess, given Antoines
strong feelings on this matter. As long as I'm not piggy-in-the-middle, I don't
have a care in this regard :)
--
___
Python tracker
Robert Collins added the comment:
This iteration provides two constructors for TracebackException, one for
exception objects, one for exc_info tuples. So it should be easy to use.
The __init__ takes the exc_info tuple because thats less code (much easier to
destructure rather than
Antoine Pitrou added the comment:
It's tedious and complicated compared to the natural way.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
___
Nick Coghlan added the comment:
Most of the time when I'm working heavily with exceptions it's something
related to contextlib, so I'm likely getting my exception details from either
sys.exc_info() or the arguments to __exit__. That means I start out with an
exception triple, and the only
Antoine Pitrou added the comment:
tb = TracebackException(*sys.exc_info, lookup_lines=False)
You don't need an exception tuple in Python 3, the exception instance is enough.
--
___
Python tracker rep...@bugs.python.org
Changes by Martin Richard mart...@martiusweb.net:
--
nosy: +martius
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
___
___
Python-bugs-list
Nick Coghlan added the comment:
I put some detailed comments in the review, but my main large scale concern is
with the traceback.Frame name. Making frame object an ambiguous phrase
seems like a bad idea to me, so I've suggested making it FrameSummary (or
FrameInfo, but on reflection I prefer
Antoine Pitrou added the comment:
Le 26/01/2015 19:36, Robert Collins a écrit :
Two key notes: the use of an exception triple is useful to ease
backports of this
Then I'd recommend making it exception-or-tuple (rather than a
*exc_info), so that both situations are satisfied.
--
Robert Collins added the comment:
Thanks for the review - shall action it all as it seems all good improvements.
Two key notes: the use of an exception triple is useful to ease backports of
this: a primary goal for me is being able to use the locals stuff in unittest
for existing production
Robert Collins added the comment:
And for profit, review changes applied (minus the small number I disagreed
with). I've clarified in the code why the exc_info tuple break out is still
used (compat with the legacy API is the strongest argument).
I haven't fleshed out the locals thing properly
Robert Collins added the comment:
actually, strike that, I'm happy with this pending a final +1 from another
reviewer. Finishing the locals stuff is a separate patch, and will look like a
single new parameter to StackSummary.extract, similarly on
TracebackException.__init__ and then change
Robert Collins added the comment:
The generator thing: the code was refactoring not so long ago to be generator
based internally with lists as a UI shim. I don't think there is a major
advantage either way. Less buffering on one hand. Less convenient in some cases
on the other. Simple use
Robert Collins added the comment:
Why do you consider it crippling?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
___
___
Nick Coghlan added the comment:
On the triple-or-value front, the main case I see for considering the you
don't need exception state triples any more argument already lost is the fact
exc_info still returns a triple, and __exit__ methods still accept them as
unpacked arguments. The C level
Antoine Pitrou added the comment:
In this view, __traceback__ is primarily about accessing *chained*
tracebacks
Please let's not make up sophistic arguments when the only motivation for
triples is backwards compatibility of *existing* APIs.
Exception triples are an unnecessary bother in
Robert Collins added the comment:
So its fairly simple IMO: it will be more code, not less, to support the
non-triple API, *and* it can be added later, unless we're proposing not to
support the triple API at all (which hasn't been proposed AFAICT).
To me thats a fairly strong argument for
Antoine Pitrou added the comment:
Le 27/01/2015 00:30, Robert Collins a écrit :
Robert Collins added the comment:
So its fairly simple IMO: it will be more code, not less, to support
the non-triple API, *and* it can be added later, unless we're proposing
not to support the triple API at
Robert Collins added the comment:
Right, and a usable API.
I believe that this will meet Guido's use case:
tb = TracebackException(*sys.exc_info, lookup_lines=False)
some time later
if should_show_tb:
lines = list(tb.format())
I'm not 100% sold on the public API being a
Robert Collins added the comment:
Stack and Frame looking good, next update will be next Monday, when I finish
off my TracebackException class.
--
Added file: http://bugs.python.org/file37782/issue17911-1.patch
___
Python tracker
Robert Collins added the comment:
I've split out the stat question to http://bugs.python.org/issue23273 - we can
optimise it slightly in this patch, but I think its scope creep here, and will
be unclear, to dive after a full fix in this issue.
--
Changes by Robert Collins robe...@robertcollins.net:
Added file: http://bugs.python.org/file37769/linecache_2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
___
Robert Collins added the comment:
This is a WIP patch, including it to just share progress.
--
Added file: http://bugs.python.org/file37770/frame_1.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
Robert Collins added the comment:
And this improves the scaling of the cache stating overhead, but we may well
want to fix this more fundamentally - e.g. by linking the cache ownership into
the import system somehow, so that when a file is reimported, the cached source
is automatically
Robert Collins added the comment:
One thing I noticed while working on this, traceback today stats each included
file once per frame per call into e.g. format_list. This might actually account
for quite some of the overhead. I'll include an optimisation for this in my new
API.
Robert Collins added the comment:
Ok, here's a draft patch for linecache. Next up, poking around the new TB API.
--
Added file: http://bugs.python.org/file37700/linecache_1.patch
___
Python tracker rep...@bugs.python.org
Robert Collins added the comment:
w.r.t. a new linecache interface, it looks like we need two attributes from
f_globals: __name__ and __loader__, so that we can eventually call
__loader__.get_source(__name__).
One small change (to let me focus on traceback) would be to add another kw
Robert Collins added the comment:
I'll put something together.
--
nosy: +rbcollins
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17911
___
___
Nick Coghlan added the comment:
Belatedly looking at this again: one thing I noticed is that the summary
currently loses info if __cause__ is set.
It would be better to follow the PEP 409/415 model and report the
__suppress_context__ flag as part of the summary, rather than dropping the
Changes by STINNER Victor victor.stin...@gmail.com:
--
title: Extracting tracebacks does too much work - traceback: add a new thin
class storing a traceback without storing local variables
___
Python tracker rep...@bugs.python.org
64 matches
Mail list logo
