namedtuple brings in likely inappropriate complexity, so it is not always simpler.
Consider the object returned by os.stat. It allows getting terms by index:
>>> import os
>>> os.stat("/dev/null")
os.stat_result(st_mode=8630, st_ino=336, st_dev=-2065165533, st_nlink=1,
st_uid=0, st_gid=0, st_size=0, st_atime=1730960121, st_mtime=1730981460,
st_ctime=1730981460)
>>> os.stat("/dev/null")[0]
8630
>>> os.stat("/dev/null")[-1]
1730981720
But that list of 10 values became locked because people do:
(mode, ino, dev, nlink, uid, gid, size, atime, mtime, ctime) = o.stat(filename)
Which means new fields are not accessible by indexing, only attribute lookup:
>>> os.stat("/dev/null").st_blksize
65536
Assuming there wasn't the historical baggage which made os.stat the way it is, why would namedtuple still be the more Pythonic solution, and simpler than a frozen dataclass?
(Historically, os.stat originally returned a tuple, then migrated to os.stat_result and named attributes, both for readability and to allow new fields, but keeping indexing for backwards compatibility support.)
Consider the object returned by os.stat. It allows getting terms by index:
But that list of 10 values became locked because people do: Which means new fields are not accessible by indexing, only attribute lookup: Assuming there wasn't the historical baggage which made os.stat the way it is, why would namedtuple still be the more Pythonic solution, and simpler than a frozen dataclass?(Historically, os.stat originally returned a tuple, then migrated to os.stat_result and named attributes, both for readability and to allow new fields, but keeping indexing for backwards compatibility support.)