On Tue, Jul 25, 2017 at 9:30 PM, MRAB <pyt...@mrabarnett.plus.com> wrote:
> On 2017-07-25 19:48, Giampaolo Rodola' wrote: > >> >> On Tue, Jul 25, 2017 at 7:49 PM, MRAB <pyt...@mrabarnett.plus.com >> <mailto:pyt...@mrabarnett.plus.com>> wrote: >> >> On 2017-07-25 02:57, Nick Coghlan wrote: >> >> On 25 July 2017 at 02:46, Michel Desmoulin >> <desmoulinmic...@gmail.com <mailto:desmoulinmic...@gmail.com>> >> wrote: >> >> Le 24/07/2017 à 16:12, Nick Coghlan a écrit : >> >> On 22 July 2017 at 01:18, Guido van Rossum >> <gu...@python.org <mailto:gu...@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
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
