The proposed use cases sound more appropriate for a "named tuple" than any sort of dictionary. (This may have been mentioned in previous discussions. I wasn't keeping track of those, though)
For the return values, yeah, a "named tuple" is probably at least as appropriate. I'm not sure a "named tuple" is necessary for the hierarchical data. (It wasn't for me in my DOM to Bunch example.)
I saw the "named tuple" thread slowly die, mainly because the most ideal solution:
(name1:val1, name2:val2)
requires a change in Python's syntax, which is a tough route to go.
This PEP isn't attempting to solve the "named tuple" problem, though if that thread picks back up again and produces a solution that also solves the problems here, I'm more than willing to merge the two PEPs.
Note that I'm not trying to solve all the problems that a "named tuple" could solve -- just the problem of converting __getattr__ syntax to dotted-attribute syntax without the need to declare a class.
Notice that I've used 'fromPairs' rather than 'fromMapping', since consistent order matters for a tuple. Comparison semantics are inherited directly from tuple, and don't care about names (they're only interested in values).
frommapping was intended to handle the recursive (hierarchical data) case. (Perhaps it needs a better name to clarify this...) The shallow conversion was handled in the Bunch constructor. I don't see that your named_tuple type handles the recursive case, does it?
Also, it seems like there has to be a better way to do the "opposite of zip()" in fromPairs(), but I sure as hell can't think of it.
I think zip(*) is usually the inverse of zip():
.>>> zip(*sorted({'x':3, 'y':8}.items()))
.[('x', 'y'), (3, 8)]Steve -- http://mail.python.org/mailman/listinfo/python-list
