pre-PEP generic objects

[Steven Bethard]

Nick Coghlan wrote:
> 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