In article <50a97de0$0$29983$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano <steve+comp.lang.pyt...@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.
--
http://mail.python.org/mailman/listinfo/python-list
