[Python-Dev] Py2.6 ideas

[Raymond Hettinger]

> 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).to_tuple()

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


Raymond