Python 2 namespace change? (was Re: [Python-Dev] Changing existing class instances)

[Christian Tismer]

Howdy, lemme try...

Vladimir Marangozov wrote:
> 
> [Jim, Chris & Guido discussing a namespace idea]
> 
> Guys, I'm lost.
> 
> Please help me understanding this idea from the start.
> 
> After rereading this whole thread, I have only a vague intuition of
> what Jim has proposed, but I fail to understand it; and believe me,
> I'm very interested in being in sync with you on the subject.
> 
> Please filter the concept from the consequences and resubmit it
> once again (in english, through examples, ascii art, whatever).

Naming it different than before, I think this formulation
hits the nail on its top:

Jim proposes a construction that yields early binding of
names, while late binding of values.

Sample layout of an association object:

<type, refcnt, key, value>
with the same key semantics as for dicts.
The key object is assigned when the association object is
created, that is when the name is seen the first time.
The value is still NULL until assigned.

Now assume a namespace object as a collection of pointers to
asso objects, and assume that it is only extended, nothing
deleted. Then, a code object can refer to such a namespace
object by giving the index of the asso object. Since the
construction of these objects will occour in the same order
after marshal/pickling, the offsets in a code object
will always be correct.

This means: There is a construction that allows to settle a name
as soon as it is seen, without necessarily assigning a value.
When a function at compile time sees a global, it tries to resolve
it by finding an association object in the module's global scope
that contains this name. If not found, it is created.
From now on, the function still doesn't know the value, but the
name has been resolved already, and it is clear where the value
slot will be, later. There is no more lookup necessary.

Jim proposed this primarily to make it easier to reload modules,
after they have been used in "from module import" style. The
"from" imported objects would not be inserted into the module's
dict as new key/value entry, but instead a namespace object
would be inserted that adds another level of indirection here.
If the value of module "module"'s object "a" in
"from module import a" changes, this change would also be visible in
our client module.
While the general idea of early name/late value binding seems to
be a promising concept to speed up/avoid dicionary lookups
in certain places, Guido has already pointed out that the
proposed semantic change to "from .. import" seems to have
hard to explain effects and is not considered a good thing.

I agree that the idea is hard to defend for the import case.
For classes and instances, I believe it can make attribute
lookups very fast (saving dictionary lookups in almost all cases),
while the space requirement can be made equal to dictionaries.

hoping it was clear enough - ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Düppelstr. 31                :    *Starship* http://starship.python.net
12163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     we're tired of banana software - shipped green, ripens at home