With a non-trivial example that uses readable attribute names, a single, long, space-delimited string becomes more a burden than a convenience, I think. Also, the amount of time saved typing is miniscule in comparison to all the rest of the development work that'll happen.

> With a non-trivial example that uses readable attribute names, a single, long, space-delimited string becomes more a burden than a convenience, I think.

For a suitable definition of “non-trivial” and “readable” (where the former is “long list of attributes” and the latter is “long attribute names”), I’d agree, but plenty of real, serious namedtuple use is for namedtuples with small numbers of short attribute names, and those are more readable (in the literal sense) this way.

OTOH, for the nontrivial, static uses, you probably want to skip right past namedtuple() with a static list of string literals for names to typing.NamedTuple with its dataclass-like syntax, including type hints, since its more readable and also supports typing.

> Also, the amount of time saved typing is miniscule in comparison to all the rest of the development work that'll happen.

Sure, but if you start passing on providing (or, on the other side, using) conveniences because each is small in isolation, the aggregate cost ends up being high.

Fair points!

Yeah, I exclusively use the typing.NamedTuple declaration these days, because it's:

  - less redundant
  - easy to add a per-attribute comment if needed
  - great when encapsulating disparate data to be able to have concrete types listed

Also keep in mind interactive use.

The space-based approach is nicer when working in a repl, even though I probably wouldn't use it.

but you now have to explain it to everyone everytime