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
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
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
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(...):
>
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
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
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
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
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