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

[Jim Fulton]

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