Is crawling the stack "bad"? Why?

[Stephen Hansen]

>
> > Seriously, crawling the stack introduces the potential for disaster in
> > your program, since there is no guarantee that the calling code will
> > provide the same environment i future released. So at best you tie your
> > solution to a particular version of a particular implementation of
> Python.
>
> I'm gathering that the general argument is entirely centered around
> portability and future-proofing of code.  This certainly makes sense.
> I could try and argue that that doesn't matter for write-once-change-
> never code, but anything I'd say there might as well be applied to an
> argument saying that writing crappy code is actually ok.  And then I
> would need to be committed for thinking that write-once-change-never
> code actually exists.  I'm making myself sick as I type this.


There's a difference between "perfect future-proofing" and writing code that
will at least minimize the amount of maintenance with Python upgrades.

Consider: if you walk the stack to get this data instead of using thread
local storage, there is zero guarantee that your code will work from one
point release to another.

It might work in 2.5.1; but a small and inconsequential bug could make
them alter the private internals of a class you're walking into so that a
variable name is different inside. They might not /need/ to-- but what if
the maintainer did a minor style update at the same time? As long as
the API is the same, the behavior the same,... it'd get through, and it
likely wouldn't even be documented in the release notes for you to
catch.

If you rely on private internals-- and local variables up your calling stack
oh so count-- then you're just inviting breakage.

The published API's aren't likely to change except extremely rarely, and
when they do they're apt to have a very clear notice provided, and there's
usually a very straight-forward way to support both.

Crawling the stack into code you don't control ties you directly to one
specific implementation, in one specific version-- if it works later, its
pure chance you can't rely on, and it could break at any point.

Relying on API's have unit tests, deprecation warnings, documentation,
and behavior reversions being classified all as bugs, all providing you
with confidence that something you code might still work in the next
point release... and likely the next major release, too.

--Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20080229/4a4f4b50/attachment-0001.html>