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

[Jim Fulton]

Christian Tismer wrote:
> 
> Tim Peters wrote:
> >
> > [Jim Fulton]
> 
> [association objects]
> 
> > Jim, I've been intrigued by this idea for all the years you've been
> > suggesting it <wink>, but I've never understood what it is you're proposing!
> > This is the Python-Dev list, so feel encouraged to present it in concrete
> > implementation terms instead of ambiguous English.  Or maybe an interface?
> 
> My guess is:

Ugh. Sorry to make you guess....

> An association object adds another level of indirection
> to namespaces and makes global variables be more like true
> variables, i.e. changing them in one place changes them
> everywhere.

Right.
 
> > Does this kind of dictionary have keys?  If so, of what type?  What type are
> > the values?  Best I can make sense of the above, the values are "association
> > objects", each of which contains a name and a value, and a key is maybe a
> > duplicate of the name in the association object to which it maps.  "A name"
> > may or may not be a string -- I can't tell.  Or maybe by "dictionary" you
> > didn't intend Python's current meaning for that word at all.  I assume "a
> > value" is a PyObject*.  The whole thrust *appears* to be to get names to map
> > to a PyObject** instead of PyObject*, but if that's the ticket I don't know
> > what association objeects have to do with it.
> 
> I don't believe that the actual implementation matters too much
> and is still open to be choosen. Here my approach:
> 
> Let an association object be a pair of a key and a value.
> The restrictions for keys may be the same as for dict keys.
> 
> We can now either use dicts as they are, inserting asso-objects
> as values and sharing the key field, or invent new dictionaries
> which have no key/value pairs at all, but just references
> to asso-objects.

Right, Replace dictentries with association object pointers.

> In either case, we have the advantage that further references
> by global use from a function or by imports will always add

to the refcount of

> to the asso-object, not to its value. This keeps the value
> changeable, like a list with one element, kind of boxed object.
> Since the asso-objects stay alive as long as they are referenced,
> they are never moved, and it is ok to refer to their address.

Yup.
 
> For a function, this means that it can resolve a global at
> compile time. If the asso-object exists already, it has a fixed
> memory address and can be placed into the code object.
> If it does not exist, it can be created in the global dictionary
> or special asso-dictionary, whatever we'll use. The value will
> be NULL in this case, and this is perfect. If we do right, a
> value will have been inserted before the function is called, or we
> will raise a name error.

exactly.

You are a great guesser! :)
 
> The idea is simply to generate fixed slots for global names
> which never move. By mentioning the name, we create such
> a slot. The slot is alive as long it is seen, i.e. refcount > 0.
> 
> There must be a general way to look these things up, either by
> the per-module dictionary, or by a specialized one. Finally
> I'd tend to do the latter, since those unitialized key/value
> asso-objects would give ambiguity what dict.keys() should
> be then. For consistency, I would hide all asso-objects in
> a special asso-collection per module. They could be placed
> into the modules dict, when their value becomes assigned
> first time.
> Alternatively, they are not created at compile time but
> at runtime, when a value is assigned. I'm not sure yet.
> 
> Now, moving on from globals to all name spaces:
> If they are all handled by the asso-approach, can we
> use it to speed up attribute access for classes and
> instances? I guess we can! But I need more thought.

Yes, it needs more thought.
 
> > > An import like:
> > >
> > >   from foo import spam
> > >
> sentence == """
> > > would copy the association between the name 'foo' and a
> > > value from module 'spam' into the current module.
> >
> > Where does the idea that 'spam' is a *module* here come from?  It doesn't
> > make sense to me, and I'm so lost I'll spare everyone my further confusions
> > <wink>.
> """
> 
> def swap_words(str, one, two):
>     pieces = string.split(str, one)
>     for i in range(len(pieces)):
>         pieces[i] = string.replace(pieces[i], two, one)
>     return string.join(pieces, two)
> 
> sentence = swap_words(sentence, "'foo'", "'spam'")

Ooh ooh, you've invented a 'Jim translator bot'!

Jim

--
Jim Fulton           mailto:jim@digicool.com
Technical Director   (888) 344-4332              Python Powered!
Digital Creations    http://www.digicool.com     http://www.python.org

Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email
address may not be added to any commercial mail list with out my
permission.  Violation of my privacy with advertising or SPAM will
result in a suit for a MINIMUM of $500 damages/incident, $1500 for
repeats.