<meta-comment>
Eek, I didn't realized this thread had continued until I happened to
notice Christian's post today.
<waaa>I get too much email</waaa>
</meta-comment>
Guido van Rossum wrote:
>
> [me]
> > > I've never liked this very much, mostly because it breaks simplicity:
> > > the idea that a namespace is a mapping from names to values
> > > (e.g. {"limit": 100, "doit": <function...>, ...}) is beautifully
> > > simple, while the idea of inserting an extra level of indirection, no
> > > matter how powerful, is much murkier.
>
> [Jim F]
> > How so? It doesn't change the mapping semantics.
>
> My assumption is that in your version, the dictionary would contain
> special <object binding> objects which then would contain the
> referenced objects. E.g. {"limit": <binding: 100>, "doit": <binding:
> <function ...>>}. Thus, d["limit"] would be that <binding> object,
> while previously it would return 100.
No. The idea is to have "association" objects. We can create
these directly if we want:
a=Association('limit',100)
print a.key, a.value # whatever
The association value is mutable, but the key is not.
A namespace object is a collection of association objects
such that no two items have the same key. Internally, this
would be very much like the current dictionary except that
instead of an array of dictentries, you'd have an array of
association object pointers. Effectively, associations
are exposed dictentries.
Externally, a namspace acts more or less like any
mapping object. For example, when someone does a getitem,
the namespace object will find the association with the
desired key and return it's value. In addition, a namspace
object would provide methods along the lines of:
associations()
Return a sequence of the associations in the namespace
addAssociation(assoc)
Add the given association to the namsspace. This
creates another reference to the association.
Changing the association's value also changes the value
in the namespace.
getAssociation(key)
Get the association associated with the key.
A setitem on a namespace modifies an existing association
if there is already an association for the given key.
For example:
n1=namespace()
n1['limit']=100
n2=namespace()
n2.addAssociation(n1.getAssociation('limit'))
print n2['limit'] # prints 100
n1['limit']=200
print n2['limit'] # prints 200
When a function is compiled that refers to a global
variable, we get the association from the global namespace
and store it. The function doesn't need to store the global
namespace itself, so we don't create a circular reference.
Note that circular references are bad even if we have
a more powerful gc. For example, by not storing the global
namespace in a function, we don't have to worry about the
global namespace being blown away before a destructor is run
during process exit.
When we use the global variable
in the function, we simply get the current value from the
association. We don't have to look it up.
Namespaces would have other benefits:
- improve the semantics of:
from spam import foo
in that you'd be importing a name binding, not a value
- Be useful in any application where it's desireable to
share a name binding.
> > Again, it would also make function global variable access
> > faster and cleaner in some ways.
>
> But I have other plans for that (if the optional static typing stuff
> ever gets implemented).
Well, OK, but I argue that the namespace idea is much simpler
and more foolproof.
> > > however it would break a considerable amount of old code,
> > > I think.
> >
> > Really? I wonder. I bet it would break alot less old
> > code that other recent changes.
>
> Oh? Name some changes that broke a lot of code?
The move to class-based exceptions broke alot of our code.
Maybe we can drop this point. Do you still think
that the namespace idea would break alot of code?
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.
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