Python's Lisp heritage

Ian Bicking ianb at colorstudy.com
Mon Jul 15 22:10:13 EDT 2002


On Mon, 2002-07-15 at 17:23, Christopher Browne wrote:
> > This does kind of defeat lexical scoping, though it avoids use of
> > globals.  While function signatures don't change, it's at the
> > sacrifice of object interfaces.  OTOH, it seems to work okay.
> 
> I'd contend that there's no "defeat" involved.  This isn't a "battle"
> with "winners" and "losers;" it's a situation of Trying to Solve
> Problems.

Well, I meant that it introduces many of the same problems as dynamic
scoping.  The biggest problem I see is that things can interact in
unfortunate ways, and it's difficult to see where information comes from
or where it is used.

Of course, there is name collision, but ignoring that, there's still
potential interaction problems.

For instance, what happens when you want to do something recursively? 
Perhaps you don't expect some function to be called repeatedly with the
same state object, but someone may later want to use it in this way. 
You may overwrite the information you had saved in some attribute, and
you don't have the call stack to insulate you from such things (here
dynamic scoping can even save you at times, though sometimes it won't
help if you wanted to get to the original value, and not later values).

The other problem is that it's hard to tell where information comes from
or is used.  Function signatures make the source of information fairly
explicit -- it's either an argument or a global, where the global is
usually a module (and easy to track).  But when you start adding
extraneous information to an object, you often come upon some mysterious
attribute access that you can't find in the class definition.  

  Ian







More information about the Python-list mailing list