Newest release issues (was: Nested Scopes)

thelazydogsback at my-deja.com thelazydogsback at my-deja.com
Sat Feb 3 01:30:05 EST 2001


i'm sure I'm not understanding things fully and also don't want to
start a religous war... (ok, what the heck...)

I've seen Py described as both a "scripting language" and "programming
language" - I think one could equally read the universe or nothing into
these adjectives, but one qualification that comes to mind that may
grant a language status in the latter camp is run-time efficiency. In
evaluating Py I was surprised that apparently the compiler creates code
such that in "f(x)" the binding for "f" is looked up in a dictionary
every time "f" is executed. (E.g, even in "for...for...f(x)") This
seems very slow (as was shown in an article showing how to optimize
Python) and allows the (dubious, IHMO) flexibility of allowing "f" to
be re-bound at will, even given the "static" nature of the syntax. I
would think that "f(x)" (calling a function that you assume to be bound
to a single fn object for the duration) is such a common metaphor that
the defualt would be to do all one could to optimize for this case. If
the user really wants the flexibily of "f" to be re-bound, (s)he should
be forced to lookup the reference and call apply() (or similar)
explicitly - this usage is also far more descriptive of the actual
effect. Anyway... I was wondering if the new "nested scope" (2 pass?)
compiler did anything differently as far as late vs. earlier binding of
the fn obj. If I'm misunderstanding the way things work, sorry...

On a related note, on "weak references" w.r.t. gc(), I thought cycles
have been collected correctly for a few versions now?

thanks,
mike





Sent via Deja.com
http://www.deja.com/



More information about the Python-list mailing list