Newest release issues (was: Nested Scopes)

[Martin von Loewis]

thelazydogsback at my-deja.com writes:

> 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.

Yes, certainly. However, run-time efficiency does not mean "as fast as
possible".

> 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

That conclusion is incorrect - dictionary lookups are very fast in
Python. By the same token, you might argue that virtual functions in
C++ and Java are very slow, because an access to the virtual function
table is necessary.

> 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.

Be assured - all that can be done has been :-)

> 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.

That would be a change in the language. Another aspect to qualify as a
programming language is that programs that use it should not break
with new releases - atleast the majority should not. Your proposed
change likely breaks more programs than acceptable.

> 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.

No, it still works the same way: accessing a global means a dictionary
lookup.

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

Sure, since 2.0. However, there are cases where objects are still kept
alive by the application when they really should go away. The typical
case is a cache: to speed-up access to some object, you cache it in a
dictionary. That makes the cached object life, even if the cache holds
the last reference. With weak references, the object will go away if
the only reference to it is from the cache.

In addition, if you produce cycles, the objects participating in the
cycle will go away only when the collector runs. If you want to clear
them as soon as the last "external" reference to the structure is
released, you should use weak references. E.g. in a tree, you could
make parent link weak. That way, the tree will go away once the
reference to the root is released, as the tree does not contain cycles
anymore.

Regards,
Martin