<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 25, 2017 at 9:30 PM, MRAB <span dir="ltr"><<a href="mailto:python@mrabarnett.plus.com" target="_blank">python@mrabarnett.plus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2017-07-25 19:48, Giampaolo Rodola' wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<br>
On Tue, Jul 25, 2017 at 7:49 PM, MRAB <<a href="mailto:python@mrabarnett.plus.com" target="_blank">python@mrabarnett.plus.com</a> <mailto:<a href="mailto:python@mrabarnett.plus.com" target="_blank">python@mrabarnett.plus<wbr>.com</a>>> wrote:<br>
<br>
    On 2017-07-25 02:57, Nick Coghlan wrote:<br>
<br>
        On 25 July 2017 at 02:46, Michel Desmoulin<br></span>
        <<a href="mailto:desmoulinmichel@gmail.com" target="_blank">desmoulinmichel@gmail.com</a> <mailto:<a href="mailto:desmoulinmichel@gmail.com" target="_blank">desmoulinmichel@gmail.<wbr>com</a>>><span class="gmail-"><br>
        wrote:<br>
<br>
            Le 24/07/2017 à 16:12, Nick Coghlan a écrit :<br>
<br>
                On 22 July 2017 at 01:18, Guido van Rossum<br></span><div><div class="gmail-h5">
                <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a> <mailto:<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>>> wrote:<br>
<br>
                    Honestly I would like to declare the bare (x=1,<br>
                    y=0) proposal dead. Let's<br>
                    encourage the use of objects rather than tuples<br>
                    (named or otherwise) for<br>
                    most data exchanges. I know of a large codebase<br>
                    that uses dicts instead of<br>
                    objects, and it's a mess. I expect the bare ntuple<br>
                    to encourage the same<br>
                    chaos.<br>
<br>
<br>
            This is the people working on big code base talking.<br>
<br>
<br>
        Dedicated syntax:<br>
<br>
             (x=1, y=0)<br>
<br>
        New builtin:<br>
<br>
             ntuple(x=1, y=0)<br>
<br>
        So the only thing being ruled out is the dedicated syntax option,<br>
        since it doesn't let us do anything that a new builtin can't<br>
        do, it's<br>
        harder to find help on (as compared to "help(ntuple)" or searching<br>
        online for "python ntuple"), and it can't be readily backported to<br>
        Python 3.6 as part of a third party library (you can't easily<br>
        backport<br>
        it any further than that regardless, since you'd be missing the<br>
        order-preservation guarantee for the keyword arguments passed<br>
        to the<br>
        builtin).<br>
<br>
    [snip]<br>
<br>
    I think it's a little like function arguments.<br>
<br>
    Arguments can be all positional, but you have to decide in what<br>
    order they are listed. Named arguments are clearer than positional<br>
    arguments when calling functions.<br>
<br>
    So an ntuple would be like a tuple, but with names (attributes)<br>
    instead of positions.<br>
<br>
    I don't see how they could be compatible with tuples because the<br>
    positions aren't fixed. You would need a NamedTuple where the type<br>
    specifies the order.<br>
<br>
    I think...<br>
<br>
<br></div></div><span class="gmail-">
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:<br>
<br>
>>> nt = ntuple(x=1, y=2)<br>
>>> nt[0]<br>
1<br>
>>> nt[1]<br>
2<br>
<br>
What's less clear is how isinstance() should behave. Perhaps:<br>
<br>
>>> t = (1, 2)<br>
>>> nt = ntuple(x=1, y=2)<br>
>>> isinstance(nt, tuple)<br>
True<br>
>>> isinstance(t, ntuple)<br>
False<br>
</span></blockquote>
<br>
Given:<br>
<br>
>>> nt = ntuple(x=1, y=2)<br>
<br>
you have nt[0] == 1 because that's the order of the args.<br>
<br>
But what about:<br>
<br>
>>> nt2 = ntuple(y=2, x=1)<br>
<br>
? Does that mean that nt[0] == 2? Presumably, yes.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Does nt == nt2?<br>
<br>
If it's False, then you've lost some of the advantage of using names instead of positions.<br>
<br>
It's a little like saying that functions can be called with keyword arguments, but the order of those arguments still matters!</blockquote><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Giampaolo - <a href="http://grodola.blogspot.com" target="_blank">http://grodola.blogspot.com</a></div><div><br></div></div></div>
</div></div>