> -----Original Message-----
> From: Python-ideas [mailto:python-ideas-bounces+tritium-
> list=sdamon....@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.
>
> >
> >
> >
> > 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....@python.org] *On
> > Behalf Of *Chris Barker
> > *Sent:* Friday, July 28, 2017 8:27 PM
> > *To:* Ethan Furman <et...@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 <et...@stoneleaf.us
> > <mailto:et...@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.bar...@noaa.gov <mailto:chris.bar...@noaa.gov>
> >
> >
> >
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas@python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
