Python Interview Questions

[Roy Smith]

In article <50a97de0$0$29983$c3e8da3$5496439d at news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python at pearwood.info> wrote:


> > The stack that's returned is a list.  It's inherently a list, per the
> > classic definition:
> 
> Er, no, it's inherently a blob of multiple text lines.

No, it's a list that looks like (taken from the doc string of the code I 
referenced):

    [('/usr/lib/.../base.py', 'get_response'),
     ('/home/songza/.../views.py', 'song_info'),
     ('/home/songza.../api.py', 'get_song'),
     ('/home/songza/.../api.py', 'api')]

[it doesn't really have ...'s in the paths; I just elided some text to 
make it easier to read]

> > * It's homogeneous.  There's nothing particularly significant about each
> > entry other than it's the next one in the stack.
> 
> The complete stack trace is inhomogeneous and immutable. I've already 
> covered immutability above: removing, adding or moving lines will 
> invalidate the stack trace. Inhomogeneity comes from the structure of a 
> stack trace. The mere fact that each line is a string does not mean that 
> any two lines are equivalent. Different lines represent different things.

No.  Each entry in the list represents a source file and a function 
name.  They're all the same "shape".  You could remove one or add 
another one, or shuffle the order, and you would have something which 
was syntactically correct and semantically meaningful (even if it didn't 
represent an actual code path.

> - drop the Traceback line and the final exception line;
> - parse the File lines to extract the useful fields;
> - combine them with the source code.

You mean, kind of like the code I cited does? :-)

I think we're going to have to let this be.  You obviously have your 
concept of what a tuple is and what a list is.  I disagree.  I don't 
think either of us is right or wrong, we just have different ways of 
thinking about things.

You come at it from a theoretical point of view.  You think of each type 
as an embodiment of certain concepts ("it represents a fixed-length 
heterogenous sequence").  Your thinking is driven by what each type was 
intended to be used for.

I come at it from a practical point of view.  To me, each type is a 
collection of methods.  I have certain operations I need to perform.  I 
pick the type which offers those operations.  If the set of operations I 
need to perform (in this case, {append, hash}) don't exist in a single 
type, I'm forced to use both types and convert from one to the other as 
needed.

The theorist understands that a chisel and a screwdriver were intended 
for different purposes, but the pragmatist gets the paint can open.