On 30 July 2017 at 20:03, Alex Walters <tritium-list@sdamon.com> wrote:
-----Original Message----- From: Python-ideas [mailto:python-ideas-bounces+tritium- list=sdamon.com@python.org] On Behalf Of Michel Desmoulin Sent: Sunday, July 30, 2017 4:19 AM To: python-ideas@python.org Subject: Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]
Le 29/07/2017 à 18:14, Alex Walters a écrit :
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.
In Python 3.6, kwargs order is preserved and guaranteed. It's currently implemented by relying on the non guaranteed dict order. But the 2 are not linked. The spec does guaranty that for now on, kwargs order is always preserved whether the dict order is or not.
MyNT = namedtuple_replacement('MyNT', 'foo bar') data = {} data['bar'] = 8675309 data['foo'] = 525600
MyNT(*data) == (525600, 8675309) # better be true, or else, we are depending on iteration order.
Did you mean "MyNT(**data)" in the last line? Either way, this is just normal predefined namedtuple creation, where the field order is set when the type is defined. Rather than being about any changes on that front, these threads are mostly about making it possible to write that first line as: MyNT = type(implicitly_typed_named_tuple_factory(foo=None, bar=None)) ... (While they do occasionally veer into discussing the idea of yet-another-kind-of-data-storage-type, that is an extraordinarily unlikely outcome) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia