[Python-Dev] Py2.6 ideas

[Larry Hastings]

Michele Simionato wrote:
> ``Contract = namedtuple('Contract stock strike volatility expiration rate 
> iscall'.split())`` is not that bad either, but I agree that this is a
> second order issue.
>   
That also nicely makes another point: this form accepts not just a list 
of strings but any iterable.  That sounds nice.  I'd vote against the 
one-string approach; it seems wholly un-Pythonic to me.  Python already 
has a parser, so don't invent your own.

Speaking of un-Pythonic-ness, the whole concept of a "named tuple" 
strikes me as un-Pythonic.  It's the only data structure I can think of 
where every item inside has two names.  (Does TOOWTDI apply to member 
lookup?)  I'd prefer a lightweight frozen dict, let's call it a "record" 
after one of the suggestions in this thread.  That achieves symmetry:
                     mutable &     immutable &
                     heavyweight   lightweight
                   +--------------------------
        positional | list          tuple
        keyword    | dict          record
For new code, I can't think of a single place I'd want to use a 
"NamedTuple" where a "record" wouldn't be arguably more suitable.  The 
"NamedTuple" makes sense only for "fixing" old APIs like os.stat.

My final bit of feedback: why is it important that a NamedTuple have a 
class name?  In the current implementation, the first identifier split 
from the argument string is used as the "name" of the NamedTuple, and 
the following arguments are names of fields.  Dicts and sets are 
anonymous, not to mention lists and tuples; why do NamedTuples need 
names?  My feeling is: if you want a class name, use a class.


/larry/