Yes, that's what I understood from Steve, and it's what I had in mind, too.
At the urging of someone from this list (Steve?, Tim?) I stared at the
table 4.1 -- my eyes hurt because somehow the PostScript version printed
with the table having overstruck characters :-). I understand the
desire of having the global namespace be passed through class definitions
to method definitions, i.e., so global and module bindings are accessible.
I note that, since local name spaces in modules (and scripts and
interactive commands) are the same as the globals, one *could* have
the global namespace of a class and function definitions be the local
namespace of the enclosing code block. The 'global' declaration would
serve to both access and modify truly global bindings:
current = [3, 4]
class PointInPage:
margin = computeMargin(); # At class definition time!
def addXY(pt):
global current
return [pt[0]+current[0]+margin,pt[1]+current[1]]
For searching and modifying non-local, non-global contexts, I can't help
wondering if Python shouldn't have the equivalent of PostScript's 'store'
primitive. Perhaps a declaration:
scoped foo # similar to the 'nonlocal' proposed before
foo = 8
would attempt to bind foo in the closest non-local namespace, if it found
a binding for 'foo' (including the global namespace), else it would bind it
in the local namespace, just as if the 'scoped' declaration wasn't there.
It would be arguable whether 'scoped' be required to do searching through
enclosing local namespaces, or whether such a search be done by default.
One could also argue whether 'global' is needed at all, perhaps being
replaced by naming conventions like, "all variables defined in the outermost
namespace should begin with a capital letter." 'Exec' would take a local
namespace (dictionary) and a list of non-local namespaces.
Then again, maybe my thinking has been warped from all the NeWS programming
I've done -- in PostScript sometimes think I :-).
As for the other topic I raised:
On Mar 2, 10:15, Guido.van.Rossum@cwi.nl wrote:
> > I also think it's worth thinking about making imported modules
> > read-only, which would help with implementation details, like faster
> > lookup.
>
> I have though of this for classes. This would make the collapsing of
> their name tables into a single hash table possible, exactly as you
> describe. In an earlier version of Python, classes were indeed
> read-only; however there are some nice tricks you can do with
> dynamically created writable classes, like implementing delegation.
When I added metaclasses to NeWS, I experimented with having a different
default metaclass, one that would build read-only classes and which had
metaclass methods to implement delegation and other dynamic operations;
e.g., the 'poseAs' Objective-C command, which has one class pretending
to be another one. The point is that one can still do delegation either
through special "privileged" functions, or metaclasses, and not lose the
potential speedup of collapsing classes.
I hope I'm making sense here.
-Rafael