On 30/08/20 3:06 pm, Steven D'Aprano wrote:
On Thu, Aug 27, 2020 at 11:13:38PM +1200, Greg Ewing wrote:
a[17, 42]
a[time = 17, money = 42]
a[money = 42, time = 17]
I don't think that something like that is exactly the intended use-case
for the feature,
I don't see why we need to pick one use case to bless as the
official "true" use case. If keyword indexing becomes a thing,
this is something that people will naturally *expect* to be
able to do with it, and it will be confusing and frustrating
if it can't be done, or is unnecessarily difficult to do.
Plus we have at least one real-world use case, i.e. xarray,
where it would be a very obvious thing to do.
But I'm sure people will want to do it, so
we should allow it even if it is an (ever-so-slight) abuse of
subscript notation.
How is it an abuse? To me it seems less of an abuse than other
uses where the keyword args *don't* represent index values.
I am confident that
I have seen dunders rejected because it would require adding new type
slots.
It's a cost-benefit tradeoff. I'm just pointing out that what
we're discussing can be implemented efficiently, if the benefits
are judged worth the effort of doing so.
Another possibility would be to have them share the slots for
the existing methods, with flags indicating which variant is
being used for each one. A given type is only going to need
either __getindex__ or __getitem__, etc., not both.
In which case, why do we need new names for the methods?
I'm not really serious about that suggestion, I was just saying
that it *could* be done if we were really paranoid about making
the type object slightly bigger. I would consider that level of
paranoia to be excessive.
As for why we need new names, it's for backwards compatibility
with code that expects to be able to call an object's __xxxitem__
methods directly, e.g. for delegation. It's not that an object
can't or won't *have* both __getitem__ and __getindex__, it's
that we don't strictly need to *optimise* access to both of
them. Dunders can exist without having type slots, they're just
slower to invoke then.
As part of this, if a class only defines one of __getitem__ and
__getindex__, the code that sets up the type object would have
to provide a wrapper for the other one that delegates to the
defined one.
"Starting in version 3.10 subscript parsing changes and item dunders
should change their signature ..."
>
class X:
if sys.version_info >= (3, 10):
# New signatures
def __getitem__(self, ...):
else:
# Old signatures
Are you volunteering to rewrite all existing Python code that
defines item dunders? :-)
Having to remember which name goes with which version is going to be
annoying and tricky,
I'm not wedded to the name __getindex__. It can be called
__newgetitem__ or __getitemwithfancyparemeterpassing__ if
people thought that would be less confusing.
--
Greg
_______________________________________________
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/GWRGC7GZ5KLTRVV7ZS6DSRFPBGS6EQ72/
Code of Conduct: http://python.org/psf/codeofconduct/
