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

2017-07-26 Thread Mike Miller
Many times in the olden days when I needed a bag o' attributes to be passed around like a struct I'd make a dummy class, then instantiate it. (A lot harder than the javascript equivalent.) Unfortunately, the modern Python solution: from types import SimpleNamespace as ns is only a few

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

2017-07-26 Thread Steven D'Aprano
On Thu, Jul 27, 2017 at 11:46:45AM +1200, Greg Ewing wrote: > Nick Coghlan wrote: > >The same applies to the ntuple concept, expect there it's the fact > >that it's a *tuple* that conveys the "order matters" expectation. > > That assumes there's a requirement that it be a tuple in > the first

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

2017-07-26 Thread Greg Ewing
Nick Coghlan wrote: The same applies to the ntuple concept, expect there it's the fact that it's a *tuple* that conveys the "order matters" expectation. That assumes there's a requirement that it be a tuple in the first place. I don't see that requirement in the use cases suggested here so

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

2017-07-26 Thread Koos Zevenhoven
On Wed, Jul 26, 2017 at 8:47 PM, Alexandre Brault wrote: > > The main use case for ntuple literals, imo, would be to replace > functions like this: > >>> def spam(...): > ... [...] > ... return eggs, ham > > With the more convenient for the caller > >>> def spam(...): >

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

2017-07-26 Thread Alexandre Brault
On 2017-07-26 01:10 PM, Steven D'Aprano wrote: > On Thu, Jul 27, 2017 at 02:05:47AM +1000, Nick Coghlan wrote: >> On 26 July 2017 at 11:05, Steven D'Aprano wrote: >>> I don't see any way that this proposal can be anything by a subtle >>> source of bugs. We have two

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

2017-07-26 Thread Ethan Furman
On 07/26/2017 09:05 AM, Nick Coghlan wrote: On 26 July 2017 at 11:05, Steven D'Aprano wrote: I don't see any way that this proposal can be anything by a subtle source of bugs. We have two *incompatible* requirements: - we want to define the order of the fields according

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

2017-07-26 Thread Steven D'Aprano
On Thu, Jul 27, 2017 at 02:05:47AM +1000, Nick Coghlan wrote: > On 26 July 2017 at 11:05, Steven D'Aprano wrote: > > I don't see any way that this proposal can be anything by a subtle > > source of bugs. We have two *incompatible* requirements: > > > > - we want to define the

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

2017-07-26 Thread Nick Coghlan
On 26 July 2017 at 11:05, Steven D'Aprano wrote: > I don't see any way that this proposal can be anything by a subtle > source of bugs. We have two *incompatible* requirements: > > - we want to define the order of the fields according to the > order we give keyword

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

2017-07-26 Thread Nick Coghlan
On 26 July 2017 at 03:49, MRAB wrote: > I don't see how they could be compatible with tuples because the positions > aren't fixed. You would need a NamedTuple where the type specifies the > order. Python 3.6+ guarantees that keyword-argument order is preserved in the