For me, a satisfactory outcome from the current PEP process would be a new
dunder, which I am calling __keyfn__, that has two possible values,
namely None or True. (And of course, the associated syntax and semantics
changes. And documentation changes. These are not minor matters.)

As __keyfn__ has only two values, storing the choice in the class requires
only a single bit (not byte, but bit). That's the memory cost. And the
run-time performance cost would also be small.

Ricky has given some examples. Here are more, all assuming
    __keyfn__ = True

First, this use of __keyfn__ would allow
   >>> d[1, 2, z=3]
to result in
   >>> d.__getitem__(1, 2, z=3)

Some further examples:
    >>> d[1, 2]
    >>> d.__getitem__(1, 2)

    >>> d[(1, 2)]
    >>> d.__getitem__((1, 2))

    >>> d[a=1, b=2]
    >>> d.__getitem__(a=1, b=2)

I find the above easy to understand and use. For Steven's proposal the
calls to __getitem__ would be

    >>> d[1, 2, z=3]
    >>> d.__getitem__((1, 2), z=3)

    >>> d[1, 2]
    >>> d.__getitem__((1, 2)

    >>> d[(1, 2)] # Same result as d[1, 2]
    >>> d.__getitem__((1, 2)) # From d[(1, 2)]

   >>> d[a=1, b=2]
    >>> d.__getitem__((), a=1, b=2)

I find these harder to understand and use, which is precisely the point
Ricky made in his most recent post. That's because there's a clear and
precise analogy between
    >>> x(1, 2, a=3, b=4)
    >>> x[1, 2, a=3, b=4]

I think it reasonable to argue adding a single bit to every class is not
worth the benefit it provides. However, this argument should be supported
by evidence. (As indeed should the argument that it is worth the benefit.)

I also think it reasonable to argue that now is not the time to allow
__keyfn__ to have values other than None or True. And that allowing further
values should require an additional PEP.

I don't recall seeing an argument that Steven's proposal is as easy to
understand and use as mine (with __keyfn__ == None).

-- 
Jonathan
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at 
https://mail.python.org/archives/list/python-ideas@python.org/message/2RGFKDQ5RHEOICGXPR3XCLVUR6VSLFDQ/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to