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

Larry Hastings larry at hastings.org
Tue Feb 20 18:56:28 CET 2007

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/

More information about the Python-Dev mailing list