How keen are you for fancier lambdas, or for fancier scoping forgetting
lambda?
> ... Perhaps a more "pythonish" solution would be to somehow promote
> Modules into something more of a first-class enviromment.
? I'm drawing a blank. More info? Or do you mean wide leather seats
and free drinks <grin> ...
> The problem is that when you add Classes and Instances and inheritance,
> I'm not always sure what the CORRECT search order SHOULD be.
I've grown to appreciate the 3-namespace rule (which, as Guido could tell
you, I squirmed over at first) precisely because I hate being "not sure".
When there are only 3 places to look (& "builtin" is no burden on the
brain, so it's more like 2 places), there are only 2 (& more like 1!)
ways to screw up. That simplicity is worth something, but doesn't seem
to be valued in this thread.
> I was just recently trying to code something that needed to resolve the
> default value of a symbol with precedence:
>
> instance-variable
> class-variable
> module-variable ( i.e. python global )
> __main__ module-variable ( Really global )
> [ and if STILL not found, use a "hardwired" default value. ]
Doesn't having five distinct defaults suggest a flaw in the human factors
of the design this scheme supports <wink>?
> Forth - another language that has dictionaries at the core of its
> implementation, calls its namespace dictionaries "VOCABULARIES"
> and links them together, so search is backwards from the current
> dictionary to the "base" dictionary. ...
forth's tree-structured dictionary appears to be much more a result of
what was most convenient to implement in the "compiler" than it was of
deliberate design (what else can you do with one-way linked lists?!).
But, forth flames aside, classical static nested scoping (CSNS) is also a
tree-structured dictionary: each block has its top-level contained
blocks as its leaves, and within any block a unique path back up to the
root (module) can be traced by crawling up the parse tree. Much the
same!
> HOWEVER, in Forth, this chained lookup happens at compile time (
> interpreter compiling into threaded-code ) - In Python the symbols are
> resolved at run time, so a costly lookup is to be avoided if possible.
I'm not sure how much name-resolution Python actually delays to run-time
anymore! In the absence of "exec" and "import *", it seems close to
being right that the compiler can, for any instance of a plain variable
name (as opposed to an instance variable name), tell whether it's local
or global/builtin (but can't distinguish between global and builtin
because anyone can fiddle a module's namespace-- including __builtin__'s
--at runtime). To whatever extent that's true, it should remain true
under CSNS (but although Guido's developed increasingly-efficient ways to
access locals, accessing non-locals efficiently may be harder).
> I'm just groping about for another solution.
That's cool! At some abstract level (i.e., one that hasn't burned me in
practice), I also feel a little discomfort that "the rules" for looking
up plain variable names have nothing in common with the rules for looking
up instance variable names. However, I suspect that under CSNS, one
could view each block as "inheriting" the variable names of its closest-
containing block, in which case the rules are about the same, except that
in CSNS each block has only one immediate "superclass". So the real
challenge is to come up with plain-variable scoping rules that are as
complicated as instance-variable rules in the presence of multiple
inheritance <0.9 grin>.
all-this-from-one-harmless-"lambda"?!-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp