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!

_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to