problem with variable scoping

Moshe Zadka moshez at math.huji.ac.il
Sun May 30 04:14:17 EDT 1999


On Sun, 30 May 1999, Tim Peters wrote:

> Static scoping still makes sense in the absence of indefinite extent (what
> you really mean by "closure"), and that's what most languages outside the
> Lisp world adopt (from C to Java).  Arbitrary namespace nesting + indefinite
> extent may be in Python2; a technical hangup with garbage collection
> prevents it in Python1, unless you simulate it by hand via default-argument
> abuse (search DejaNews if you're intrigued).

Yes, I know that trick. And actually, IMHO, a better simulation would be
via classes and that wonderful __call__ special form.
(Reason: works better with variable length argument lists)

> > still-waiting-for-arbitary-expressions-in-lambdas-
> 
> Already there:  they're called "def".  Honest!  lambda is nothing but
> syntactic sugar for a particularly simple form of def in Python, and adds no
> power to the language.  All in all, lambda shouldn't have been added; it's
> not what people expect it to be, so just provokes endlessly useless
> arguments (useless because it's too late to change).

Oh, come on, you expect me to write:
def incr(x): return x+1
l=map(incr, l)

Instead of
l=map(lambda x: x+1, l)

Ouch!!!!

 
> > and-tail-call-optimization-which-is-possible-in-python-ly y'rs, Z.
> 
> It's not possible to identify a tail call at compile time (no name->object
> binding is known at compile-time, and e.g. the "f(n-1)" appearing inside a
> "def f:" may indeed notrefer to the function f, or even to a function at
> all, at runtime).

Hey, Tim, you know I put that part in just to cause you to say it isn't so
I could answer more fully <wink>.

OK: Notice ``tail *call* optimization'', not ``tail *recursion*
optimization'', which is a special case anyway (and not resembling a blue
sphere at all).

Whenever the python interpreter sees something like

def f(...):
	.
	.
	.
	return g(...)

It could generate code for the stack popping *before*, rather then *after*
the evaluation of g(...), since f(..) and its parameters are useless
(unless, of course, someone decides to play with the frames inside g, in
which case, he/she deserve to get shot)

> Bottom line:  Anyone who intends to stick with Python is well-advised to
> learn how to write a loop <wink>.
> 
> the-best-language-to-code-scheme-in-remains-scheme-ly y'rs  - tim

Well, my paradigm is ``think in Scheme, write in Python, optimize in C''.
It sort of works, and though Guido would hate me for that, I'm sad that
too much gets lost in the translation.

though-i-find-i-can-live-w/o-continuations-so-guido-needn't-worry-ly y'rs,
Z.

--
Moshe Zadka <mzadka at geocities.com>. 
QOTD: My own exit is more likely to be horizontal then perpendicular.






More information about the Python-list mailing list