On Tue, 25 Aug 2020 at 22:42, Ricky Teachey <ri...@teachey.org> wrote:
> Actually I think this *may not* be true. Consider, if we were starting at
> zero ,and we agreed we wanted dict literal behavior to work like the
> following:
>
> >>> idx1 = 1,2,3
> >>> idx2 = 1,2
> >>> idx3 = 1
> >>> d = {idx1: "foo", idx2: "bar", idx2: "baz"}
>
> This is what we have today, and I think most agree this is all a Good Thing.
>
> Then, we might reason, if I want to be able to do a lookup using tuple
> literals, I'd do this, just as we do today:
>
> >>> d[1,2,3]
> 'foo'
> >>> d[1,2]
> 'bar'
> >>> d[1]
> 'baz'
>
> No tuple brackets required.
>
> I think it is REALLY NICE not to have to do THIS, which is what we'd have to
> do if things behaved the function-call-way inside square brackets:
>
> >>> d[(1,2,3)]
> 'foo'
> >>> d[(1,2)]
> 'bar'
> >>> d[1]
> 'baz'
>
> Of course all of these DO work today-- it just isn't required to use the
> tuple brackets. They're optional.
>
> Could it be that the convenience of not needing to give the tuple brackets,
> if we were starting at zero, might win out over the function-call syntax even
> today? I don't know. I wonder.
If we were to start from scratch, dict.__getitem__ would probably
accept *args, **kwargs, and use them to create the index.
I would also say that very likely it would not accept kwargs at all.
But you have a point that whatever the implementation might be, it has
to play nice with the current dict() behavior. Yet, if we were to add
an enhanced dunder, nothing for the current dict would change. It
would still use the old getitem, and it would still create a tuple
from its (nameless) index group to be used as a key.
--
Kind regards,
Stefano Borini
_______________________________________________
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/XR6SFHPVCXE5D4IB77MBDKNT36DHU276/
Code of Conduct: http://python.org/psf/codeofconduct/
