Python Interview Questions
steve+comp.lang.python at pearwood.info
Tue Nov 20 00:42:17 CET 2012
On Mon, 19 Nov 2012 09:30:54 -0500, Roy Smith wrote:
> In article <50a9e5cf$0$21863$c3e8da3$76491128 at news.astraweb.com>,
> Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:
>> I see. It wasn't clear from your earlier description that the items had
>> been post-processed from collections of raw log lines to fixed records.
> Well, I did provide the code that does this.
You did? When? [goes back and looks]
Oh, so you did. Oops.
By the way, your news client seems to be mangling long URLs, by splitting
them when they exceed the maximum line length. I didn't follow the link
you gave because it was mangled, and then forgot it even existed. Sorry
> You really might want to read the code I provided. Here's the reference
And mangled again :)
> The "header" referred to does indeed contain the exception raised. And
> the line numbers are included. Here's a typical output stanza:
Ian Kelly has picked up on what I'm trying to say. You might collect the
traceback in the "header", but it doesn't get used in the key, and each
time you find a repeated stack trace, you toss away whatever header you
just saw and keep the header you saw the first time.
header, stack = traceback_helper.extract_stack(lines)
signature = tuple(stack)
if signature in crashes:
count, header = crashes[signature]
crashes[signature] = (count + 1, header)
crashes[signature] = (1, header)
In general, it is an unsafe assumption that the actual exception raised
will be the same just because the stack trace is the same. So as I said,
if you have two *distinct* failures occurring in the same function (not
even necessarily on the same line), your code appears to treat them as
the same error. That seems odd to me, but if you have a good reason for
doing it that way, so be it.
More information about the Python-list