Python Interview Questions

Steven D'Aprano steve+comp.lang.python at
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>,
>  Steven D'Aprano <steve+comp.lang.python at> 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 
about that.

> You really might want to read the code I provided.  Here's the reference
> again:

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)
[end quote]

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 mailing list