On Tue, Jul 25, 2017 at 9:30 PM, MRAB <python@mrabarnett.plus.com> wrote:
On 2017-07-25 19:48, Giampaolo Rodola' wrote:
On Tue, Jul 25, 2017 at 7:49 PM, MRAB <python@mrabarnett.plus.com <mailto:python@mrabarnett.plus.com>> wrote:
On 2017-07-25 02:57, Nick Coghlan wrote:
On 25 July 2017 at 02:46, Michel Desmoulin <desmoulinmichel@gmail.com <mailto:desmoulinmichel@gmail.com>> wrote:
Le 24/07/2017 à 16:12, Nick Coghlan a écrit :
On 22 July 2017 at 01:18, Guido van Rossum <guido@python.org <mailto:guido@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