On 2020-08-27 12:33 a.m., Ricky Teachey wrote:
On Wed, Aug 26, 2020 at 10:34 PM Steven D'Aprano <st...@pearwood.info
<mailto:st...@pearwood.info>> wrote:
On Wed, Aug 26, 2020 at 12:32:56PM -0400, Ricky Teachey wrote:
> It creates a language supported way for the creator of the class
to decide
> how to interpret the contents inside a subscript operation.
We already have that: `__getitem__`.
Actually no, we have /THREE/ dunders: get, set, and del -item. And
they accept a single argument containing a single object representing
a single key or index. And if I had to make a prediction, then
probably pretty soon they'll accept kwargs, too.
And these are great as-is when the way you want to use them is in
total agreement with the way they were envisioned to be used: for
single argument keys/indexes.
But any use case that deviates from that vision requires effort spread
across three dunder methods to set it up right. And it requires
writing code that breaks up the positional arguments in just the right
way; code that you pretty much never have to write when using the
function paradigm (rather than the item dunder paradigm), because the
language does it all for us:
I'm not seeing what problem adding a new dunder and indirection of
__*item__ solves that isn't solved by something like
class K:
def _make_key(self, index, **kwargs): # Where **kwargs is any kind
of keywordey params, not necessarily just a **kwargs
return 'something'
def __getitem__(self, index, **kwargs):
key = self._make_key(index, **kwargs)
...
def __delitem__(self, index, **kwargs):
key = self._make_key(index, **kwargs)
...
def __setitem__(self, index, value, **kwargs):
key = self._make_key(index, **kwargs)
...
Sure, on a pedantic level I had to put effort across three dunders, but
the effort is a single method call *and* I would still have needed to do
it in the __subscript__ scenario except I would also have to have
written a __subscript__ that is a combination of _make_key and
boilerplate to call the method that the interpreter would have
previously called for me.
Alex
_______________________________________________
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/BYE6ULJLUQUOTU2CEMZOJAGTGJHRNFRL/
Code of Conduct: http://python.org/psf/codeofconduct/
