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