[Python-Dev] NamedTuple (was: Py2.6 ideas)

[Jim Jewett]

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