[Python-Dev] Py2.6 ideas (original) (raw)

Raymond Hettinger python at rcn.com
Sat Feb 17 00:06:14 CET 2007

Raymond Hettinger schrieb:

d, g, v, t, r = model(somecontract)

[MvL]

I find that line quite unreadable

Of course, I can't give you the fully spelled-out line from proprietary code. But at this point we're just talking about the use cases for tuples with or without named attributes. Some functions return multiple values and some calls to those functions do tuple unpacking. That is ubiquitous throughout Python. If the tuple also happens to be a NamedTuple, you get tooltips for it (reminding you which fields are which) and any error messages will show the full repr with both the names and values.

If not unpacked, then the attribute access is helpful. Something like contract.vega or testresult.failures or somesuch.

Essentially, I'm proposing a variant of tuple that has self-documenting extra features:

 traditional positional arguments construction or option keyword argument

construction annotated repr: Contract(type='put', strike=45, security='IBM', expirymonth=4) instead of: ('put', 45, 'IBM, 4) optional attribute access: contract.strike nice docstring for tooltips: 'Contract(type, strike, security, expirymonth)'

The use cases are the same as the ones for tuples. The new type is just more self-documenting. That's all there is to it.

FWIW, I've been using NamedTuples for at least six months and have found them to be a nice improvement over straight-tuples in situations where I can't easily remember what each tuple position represents. If added to the collections module, I think NamedTuples will become quite popular.

If you absolutely want tuple unpacking on a record-like object, I'd suggest to support explicit tuple conversion, like

d, g, v, t, r = model(somecontract).totuple()

Entirely unnecessary. The goal is to have better tuples with low overhead and a near zero learning curve.

Raymond

More information about the Python-Dev mailing list