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

Giampaolo Rodola' g.rodola at gmail.com
Tue Jul 25 16:48:14 EDT 2017


On Tue, Jul 25, 2017 at 9:30 PM, MRAB <python at mrabarnett.plus.com> wrote:

> 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!


Mmmm excellent point. I would expect "nt == nt2" to be True because
collections.namedtuple() final instance works like that (compares pure
values), because at the end of the day it's a tuple subclass and so should
be ntuple() (meaning I expect "isinstance(ntuple(x=1, y=2), tuple)" to be
True).

On the other hand it's also legitimate to expect "nt == nt2" to be False
because field names are different. That would be made clear in the doc, but
the fact that people will have to look it up means it's not obvious.

-- 
Giampaolo - http://grodola.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170725/e803da0a/attachment.html>


More information about the Python-ideas mailing list