Raymond Hettinger explained:
The constructor signature ... Point(*fetchall(s)), and it allows for direct construction with Point(2,3) without the slower and weirder form: Point((2,3)).
If you were starting from scratch, I would agree whole-heartedly; this is one of my most frequent mistakes. The question is whether it makes sense to "fix" NamedTuple without also fixing regular tuple, list, set, etc. Assuming this goes to collections rather than builtins, would it be reasonable to include both versions?
Also, the current signature works better with keyword arguments: Point(x=2, y=3) or Point(2, y=3) which wouldn't be common but would be consistent with the relationship between keyword arguments and positional arguments in other parts of the language.
Yes and no. One important trait of (pre 2.6) keyword arguments is that they have defaults. When I'm using a record format that someone else defined, it is pretty common for large portions of most records to be essentially wasted. It would be nice if I could create a record by just specifying the fields that have non-default values. I can do this with a data class (since attribute lookup falls back to the class), but not with this tuple factory.
The string form for the named tuple factory was arrived at because it was easier to write, read, and alter than its original form with a list of strings:
Contract = namedtuple('Contract stock strike volatility expiration rate iscall') vs. Contract = namedtuple('Contract', 'stock', 'strike', 'volatility', 'expiration', 'rate', 'iscall')
The type name is somehow different. Do either of these affect your decision? # separate arguments for type name and field names Contract = namedtuple('Contract', "stock strike volatility expiration rate iscall") # no explicit assignment, and bad hackery to get it namedtuple('Contract', "stock strike volatility expiration rate iscall") -jJ