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:
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.
> 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.
In either case, we have the advantage that further references
by global use from a function or by imports will always add
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.
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.
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.
> > 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'")
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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4