empty classes as c structs?

[Nick Coghlan]

Michael Spencer wrote:
> Nick Coghlan wrote:
>> The other issue is that a namespace *is* a mutable object, so the 
>> default behaviour should be to make a copy
>>
> I 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   |   ncoghlan at email.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.skystorm.net