[Python-Dev] Re: Re: Patch review: [ 1094542 ] add Bunch type to collections module

[Fernando Perez]

Steven Bethard wrote:

> Fernando Perez <fperez.net at gmail.com> wrote:

> My feeling about this is that if the name of the attribute is held in
> a variable, you should be using a dict, not a Bunch/Struct.  If you
> have a Bunch/Struct and decide you want a dict instead, you can just
> use vars:
> 
> py> b = Bunch(a=1, b=2, c=3)
> py> vars(b)
> {'a': 1, 'c': 3, 'b': 2}

Well, the problem I see here is that often, you need to mix both kinds of
usage.  It's reasonable to have code for which Bunch is exactly what you need
in most places, but where you have a number of accesses via variables whose
value is resolved at runtime.  Granted, you can use getattr(bunch,varname), or
make an on-the-fly dict as you indicated above.  But since Bunch is above all
a convenience class for common idioms, I think supporting a common need is a
reasonable idea.  Again, just my opinion.

>> Another useful feature of this Struct class is the 'merge' method.
> [snip]
>> my values() method allows an optional keys argument, which I also
>> find very useful.
> 
> Both of these features sound useful, but I don't see that they're
> particularly more useful in the case of a Bunch/Struct than they are
> for dict.  If dict gets such methods, then I'd be happy to add them to
> Bunch/Struct, but for consistency's sake, I think at the moment I'd
> prefer that people who want this functionality subclass Bunch/Struct
> and add the methods themselves.

It's very true that these are almost a request for a dict extension.  Frankly,
I'm too swamped to follow up with a pep/patch for it, though.  Pity, because
they can be really useful... Takers?

> I'm probably not willing to budge much on adding dict-style methods --
> if you want a dict, use a dict.  But if people think they're
> necessary, there are a few methods from Struct that I wouldn't be too
> upset if I had to add, e.g. clear, copy, etc.  But I'm going to need
> more feedback before I make any changes like this.

You already have update(), which by the way precludes a bunch storing an
'update' attribute.  My class suffers from the same problem, just with many
more names.  I've thought about this, and my favorite solution so far would be
to provide whichever dict-like methods end up implemented (update, merge (?),
etc) with a leading single underscore.  I simply don't see any other way to
cleanly distinguish between a bunch which holds an 'update' attribute and the
update method.  

I guess making them classmethods (or is it staticmethods? I don't use those so
I may be confusing terminology) might be a clean way out:

Bunch.update(mybunch, othermapping) -> modifies mybunch.

Less traditional OO syntax for bunches, but this would sidestep the potential
name conflicts.

Anyway, these are just some thoughts.  Feel free to take what you like.

Regards,

f