First, thanks for the answer :). Here is my input on the topic [Obviously I won't be present the developer day] From: Jeremy Hylton <jeremy@alum.mit.edu>
The approach I'm working on would have to check that the object is a module on each use, but that's relatively cheap compared to the layers of function calls we have now. It's a pretty safe assumption because it would only be made for objects bound by an import statement.
I also wanted to answer Samuele's question briefly, because I'm going to be busy with other things most of today. The basic idea, which I need to flesh out by next week, is that the internal binding for "mod.attr" that a module keeps is just a hint. The compiler notices that function f() uses "mod.attr" and that mod is imported at the module level. The "mod.attr" binding must include a pointer to the location where mod is stored and the pointer it found when the "mod.attr" binding was updated. When "mod.attr" is used, the interpreter must check that mod is still bound to the same object. If so, the "mod.attr" binding is still valid. Note that the "mod.attr" binding is a PyObject ** -- a pointer to the location where "attr" is bound in "mod".
I see, btw I asked primarily because the PEP as it is is vague, not because I believed the idea cannot fly [for Jython the issue is more complicated, PyObject ** is not something easily expressed in Java <wink>] I think that it is worth to point out that what you propose is a special/ ad-hoc version of what typically other Smalltalk-like dynamic languages do, together with jitting, but the approach is orthogonal to that, namely: for every send site they have a send-site cache: if send-site-cache-still-applies: # (1) dispatch based on site-cache contents # (2) else: normal send lookup and update send-site-cache In Python more or less the same could be applied to load_* instead of sends. Your approach deals with a part of those. These need (only) module-level caches. The extended/general approach could work too and give some benefit. But it is clear that the complexity and overhead of (1) and (2), and the space-demand for the caches depend on how much homogeneous are system object layouts and behaviors. And Python with modules, data-objects, class/instances, types etc is quite a zoo :(. Pushing the class/type unification further, this is an aspect to consider IMHO. If those things where already all known sorry for the boring post. regards.