My $0.02 on the entire series of nametuple threads is… there *might* be value in an immutable namespace type, and a mutable namespace type, but namedtuple’s promise is that they can be used anywhere a tuple can be used. If passing in kwargs to create the potential replacement to namedtuple is sensitive to dict iteration order, it really isn’t a viable replacement for namedtuple. I do feel like there isn’t that big of a usecase for an immutable namespace type as there is for a namedtuple. I would rather namedtuple class creation be quicker. From: Python-ideas [mailto:python-ideas-bounces+tritium-list=sdamon.com@python.org] On Behalf Of Chris Barker Sent: Friday, July 28, 2017 8:27 PM To: Ethan Furman <ethan@stoneleaf.us> Cc: Python-Ideas <python-ideas@python.org> Subject: Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple] On Thu, Jul 27, 2017 at 7:42 PM, Ethan Furman <ethan@stoneleaf.us <mailto:ethan@stoneleaf.us> > wrote: How I get the point[0] == 3? The first definition of an ntuple had the order as x, y, and since the proposal is only comparing field names (not order), this (y, x) ntuple ends up being reversed to how it was specified. I'm not sure there ever was a "proposal" per se, but: ntuple(x=a, y=b) had better be a different type than: ntuple(y=b, x=a) but first we need to decide if we want an easy way to make an namedtuple-like object or a SimpleNemaspace-like object.... but if you are going to allow indexing by integer, then order needs to be part of the definition. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov <mailto:Chris.Barker@noaa.gov>