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

[MRAB]

On 2017-07-25 19:48, Giampaolo Rodola' wrote:
>
> On Tue, Jul 25, 2017 at 7:49 PM, MRAB <python at mrabarnett.plus.com 
> <mailto:python at mrabarnett.plus.com>> wrote:
>
>     On 2017-07-25 02:57, Nick Coghlan wrote:
>
>         On 25 July 2017 at 02:46, Michel Desmoulin
>         <desmoulinmichel at gmail.com <mailto:desmoulinmichel at gmail.com>>
>         wrote:
>
>             Le 24/07/2017 à 16:12, Nick Coghlan a écrit :
>
>                 On 22 July 2017 at 01:18, Guido van Rossum
>                 <guido at python.org <mailto:guido at python.org>> wrote:
>
>                     Honestly I would like to declare the bare (x=1,
>                     y=0) proposal dead. Let's
>                     encourage the use of objects rather than tuples
>                     (named or otherwise) for
>                     most data exchanges. I know of a large codebase
>                     that uses dicts instead of
>                     objects, and it's a mess. I expect the bare ntuple
>                     to encourage the same
>                     chaos.
>
>
>             This is the people working on big code base talking.
>
>
>         Dedicated syntax:
>
>              (x=1, y=0)
>
>         New builtin:
>
>              ntuple(x=1, y=0)
>
>         So the only thing being ruled out is the dedicated syntax option,
>         since it doesn't let us do anything that a new builtin can't
>         do, it's
>         harder to find help on (as compared to "help(ntuple)" or searching
>         online for "python ntuple"), and it can't be readily backported to
>         Python 3.6 as part of a third party library (you can't easily
>         backport
>         it any further than that regardless, since you'd be missing the
>         order-preservation guarantee for the keyword arguments passed
>         to the
>         builtin).
>
>     [snip]
>
>     I think it's a little like function arguments.
>
>     Arguments can be all positional, but you have to decide in what
>     order they are listed. Named arguments are clearer than positional
>     arguments when calling functions.
>
>     So an ntuple would be like a tuple, but with names (attributes)
>     instead of positions.
>
>     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.
>
>     I think...
>
>
> Most likely ntuple() will require keyword args only, whereas for 
> collections.namedtuple they are mandatory only during declaration. The 
> order is the same as kwargs, so:
>
> >>> nt = ntuple(x=1, y=2)
> >>> nt[0]
> 1
> >>> nt[1]
> 2
>
> What's less clear is how isinstance() should behave. Perhaps:
>
> >>> t = (1, 2)
> >>> nt = ntuple(x=1, y=2)
> >>> isinstance(nt, tuple)
> True
> >>> isinstance(t, ntuple)
> False

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.

Does nt == nt2?

If it's False, then you've lost some of the advantage of using names 
instead of positions.

It's a little like saying that functions can be called with keyword 
arguments, but the order of those arguments still matters!