Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

On Wed, Jul 26, 2017 at 11:58:44AM +1200, Greg Ewing wrote: > If we're going to have such a type, I suggest making it a > pure named-fields object without any tuple aspects. In which > case "ntuple" wouldn't be the right name for it, and something > like "record" or "struct" would be better.

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

On Tue, Jul 25, 2017 at 08:30:14PM +0100, MRAB wrote: > Given: > > >>> nt = ntuple(x=1, y=2) > > you have nt[0] == 1 because that's the order of the args. > > But what about: > > >>> nt2 = ntuple(y=2, x=1) > > ? Does that mean that nt[0] == 2? Presumably, yes. It better be. > Does nt ==

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

Nick Coghlan wrote: New builtin: ntuple(x=1, y=0) Do we really want this to be a tuple, with ordered fields? If so, what determines the order? If it's the order of the keyword arguments, this means that ntuple(x=1, y=0) and ntuple(y=0, x=1) would give objects with different

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

On Thu, Jul 20, 2017 at 3:35 AM, Alexander Belopolsky < alexander.belopol...@gmail.com> wrote: > On Wed, Jul 19, 2017 at 9:08 PM, Guido van Rossum > wrote: > > The proposal in your email seems incomplete > > The proposal does not say anything about type((x=1, y=2)). I assume >

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

On Tue, Jul 25, 2017 at 9:30 PM, MRAB wrote: > On 2017-07-25 19:48, Giampaolo Rodola' wrote: > >> >> On Tue, Jul 25, 2017 at 7:49 PM, MRAB > > wrote: >> >> On 2017-07-25 02:57, Nick Coghlan wrote: >>

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

On 2017-07-25 19:48, Giampaolo Rodola' wrote: On Tue, Jul 25, 2017 at 7:49 PM, MRAB > wrote: On 2017-07-25 02:57, Nick Coghlan wrote: On 25 July 2017 at 02:46, Michel Desmoulin

Re: [Python-ideas] Idea : for smarter assignment?

On 7/25/17, MRAB wrote: > On 2017-07-25 18:02, Nick Timkovich wrote: >> On Fri, Jul 21, 2017 at 12:59 PM, David Mertz > > wrote: >> >> But you've left out quite a few binding operations. I might forget >> some, but

Re: [Python-ideas] Idea : for smarter assignment?

On 2017-07-25 18:02, Nick Timkovich wrote: On Fri, Jul 21, 2017 at 12:59 PM, David Mertz > wrote: But you've left out quite a few binding operations. I might forget some, but here are several: Ned Batchelder had a good presentation at PyCon

Re: [Python-ideas] Idea : for smarter assignment?

On Wed, Jul 26, 2017 at 3:02 AM, Nick Timkovich wrote: > ...I think only includes one other assignment type from what you listed > (function parameters) that ironically is where one could maybe blur =/:, as > doing f(x=3) and f(**{x: 3}) are usually similar (I think some

Re: [Python-ideas] Idea : for smarter assignment?

On Fri, Jul 21, 2017 at 12:59 PM, David Mertz wrote: > > But you've left out quite a few binding operations. I might forget some, > but here are several: > Ned Batchelder had a good presentation at PyCon 2015 about names/values/assignments/binding:

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

Steven, (short of time here) With **kwargs and a little more work, the function would check if the type is already defined, and retur the ntuple with the correct type, not the type. Your sketch of a solution convinced me it can be done with a library function; no additional syntax needed.

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

C Anthony Risinger writes: > At the end of the day, I don't see a way to have both a literal and > something that is externally "named", because the only ways to pass the > name I can imagine would make it look like a value within the container > itself (such as using a literal string for the

Re: [Python-ideas] namedtuple redesign goals

Michel Desmoulin writes: > You are assuming a namedtuple litteral would mean > collections.namedtuple would lose the type hability. It's not the > case. The litterals can be complement, not a remplacement. Unlikely to fly in Python. We really don't like things that have "obvious semantics"