Re: Lambda binding solved?

Guido.van.Rossum@cwi.nl
Wed, 02 Mar 1994 10:15:31 +0100

> I think that making Modules a first class environment (like packages
> in NeWS) is an elegant solution to the name scoping problem.

What exactly does "first class environment" mean? If I understand it
correctly, say we have a module "names" defining two functions
module() and resolve(), and let's say the keyword to add a new
first-class is "require", then we could say "require names" with
roughly the same meaning as "from names import *", except that the
current scope would probably have precedence. Have I got that right?

Now if we have two require statements, in what order would they be
searched? Say we have some code like "require a, b; require c"; would
the search order be <current>, a, b, c; or <current>, c, b, a; or
<current>, c, a, b, or perhaps a, b, c, <current>?

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

I have also thought of somehow unifying modules and classes, since
most of the implementation of modules is duplicated for classes
(though not the other way around). Then the "require" statement could
manipulate the list of base classes (which would have to be turned
into a list since tuples cannot be extended).

Unsure-how-this-will-help-solving-the-lambda-problem,

--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
URL: <http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>