Nick Coghlan wrote:The other issue is that a namespace *is* a mutable object, so the default behaviour should be to make a copyI don't follow this argument. Why does mutability demand copy? Given that somedict here is either a throwaway (in the classic bunch application ) or a dict that must be updated (the wrap-dict case), copying doesn't make much sense to me.
OTOH, dict.__init__(dict) copies. hmmmm....
As you noticed, it's a precedent from the other builtins and objects in the standard library. The mutable ones (dict, list, set, etc) all make a copy of whatever you pass in.
This is to allow easy copying of an existing namespace -
Can't this be spelled namespace(somenamespace).__copy__()?
Again, as Steven mentioned, this is based on precedent from other objects in the interpreter. To get your own copy of a mutable type, you invoke the constructor with the original as the sole argument.
> for anything else, invoking vars() is easy enough.
If there is potential for confusion, I'd be tempted to disallow namespaces as an argument to update/__update__
Limiting confusion is why I decided to restrict the special-case of querying the __dict__ to instances of namespace. Again, as Steven pointed out, the semantics get screwed up when the object supplied is usable as a dictionary, but also has a __dict__ attribute.
For a namespace, the special case means that namespace(ns_obj) and namespace(vars(ns_obj)) have the same result. Just don't go creating a namespace subclass which provides a direct mapping interface to anything other than it's own __dict__ and expect to affect namespaces created using the normal constructor. I figure that limitation is obscure enough that we can live with it :)
For an arbitrary object, you can poke around in its __dict__ by doing: namespace.view(vars(obj))
We could use __add__, instead for combining namespaces
Update already let's us combine namespaces. To create a new object that merges two namespaces do:
namespace.update(namespace(ns_1), ns_2)
Good idea. The implementation ought to be tested against several plausible specializations.
One thing I'm going to drop is the ability to use an arbitrary class as a subrecord. I realised it screws up storage of classes and class instances which have a __dict__ attribute.
Instead, I'll change it so that the optional argument allows you to set some of the attributes.
I don't like the sound of that. The whole point here - whether as Steven's nice straightforward bunch, as originally conceived, or the other cases you and I and others have been 'cluttering' the discussion with ;-) is convenience, and readability. If there are hoops to jump through to use it, then the benefit is quickly reduced to zero.
Yes, once I realised that the polymorphism friendly 'type(self).update(self, other)' works with a classmethod, I realised it made sense to go with Steven's classmethod approach.
I'll also revert to his *args based solution to the keyword argument problem, too.
Time to go play cricket, so I won't actually be posting any of the above changes tonight :)
Cheers, Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list
