Favorite non-python language trick?
mwm at mired.org
Sat Jul 2 04:23:05 CEST 2005
[Lots of quoted text left in...]
I started thinking about this, and realized that there was a way to do
what you wanted, with no execution time overhead, and without
providing ways to radically change the program behavior behind the
Mike Meyer <mwm at mired.org> writes:
> "Shai" <shai at platonix.com> writes:
>> Joseph Garvin wrote:
>>> I'm curious -- what is everyone's favorite trick from a non-python
>>> language? And -- why isn't it in Python?
>> 1. Lisp's "dynamically scoped" variables (Perl has them, and calls them
>> "local", but as far as I've seen their use their is discouraged). These
>> are global variables which are given time-local bindings. That is,
>> structuring the syntax after what's used for globals,
> Perl started life with nothing but dynamically scoped variables. They
> added lexical scoping after they realized what a crock dynamic scoping
That's a bit harsher than I intended. I mean that having nothing but
dynamically scoped variables - like early Perl and LISP - is a
crock. I'll add that dynamic scoping as the default is a crock. But
you aren't asking for those.
>> def foo():
>> # No need to define x as it is only read -- same as globals
>> print x
>> def bar():
>> dynamic x
>> x = 11
>> def baz():
>> bar() # prints 11
>> foo() # prints 10; the binding in bar is undone when bar exits
Here's the problem with that. Consider this script:
x = 10
If foo.foogle includes "dynamic x" and then invokes bar, bar could
print anything. This makes the behavior of bar unpredictable by
examining the sourc, with no hint that that is going on.
> Given that it's a feature I don't want programmers using, I'd only be
> willing to see it added to the language if you can show that it has no
> overhead so long as you don't use it. I'm not sure that can be done.
Here's a proposal for dynamically bound variables that you should be
able to implement without affecting the runtime behavior of code that
doesn't use it.
Instead of dynamic meaning "all references to the named variable(s)
will be dynamic until this function exits", have it mean "the named
variable(s) will be dynamic in this function." Whether it should only
check local variables in the calling routines, check local + global,
or check for all free variables, is an open question.
I.e. - your example would be written:
x = 10
x = 11
bar() # prints 11
foo() # Possibly an error?
For my example above, bar would *always* print 10. Nothing that
foo.foogle did would change that. However, you could write:
In this case, bar will print whatever foo.foogle sets x to - and it's
noted in the source to bar. This means that functions that don't
declare a dynamic variable can be compiled to the same code they are
compiled to now.
Would this version provide the functionality you wanted?
Mike Meyer <mwm at mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
More information about the Python-list