On Sun, Aug 30, 2020 at 05:49:50PM +1200, Greg Ewing wrote: > 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.
We do that for every other operator and operator-like function. Operator overloading is a thing, so if you want `a + b` to mean looking up a database for `a` and writing it to file `b`, you can. But the blessed use-cases for the `+` operator are numeric addition and sequence concatenation. Anything else is an abuse of the operator: permitted, possibly a *mild* abuse, but at best it's a bit wiffy. (There are a few gray areas, such as array/matrix/vector addition, which sneak into the "acceptable" area by virtue of their long usage in mathematics.) If you don't like the term "abuse", I should say I am heavily influenced by its use in mathematics where "abuse of notation" is not considered a bad thing: https://en.wikipedia.org/wiki/Abuse_of_notation In any case, as you say (and agreeing with me) people will want to do something like this, and it is not my intent to stop them. > Plus we have at least one real-world use case, i.e. xarray, > where it would be a very obvious thing to do. Indeed, and I can think of at least two use-cases where I would immediately use it myself, if I could. > >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. Compares to the majority of realistic examples given in this discussion and the PEP, your example doesn't look to me like an item or key lookup. It looks more like a function call of some sort. I know that, in a sense, subscript lookups are like function calls, and I also acknowledge that I don't know your intended semantics of that example. It might even be that you intended it as a lookup of some kind of record with time=17 and money=42. But let's not get too bogged down into not-picking. We agree that people should be allowed to do this. [...] > >"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? :-) Of course not. This is why we ought to be cautious about introducing backwards-incompatible changes. I don't think that we should care about this "problem" that subscripting only takes a single subscript. But if we do "fix" it, I'd rather the straight-forward future directive (and a long, long deprecation period for the old behaviour) than two sets of confusingly similar getters and setters. > >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. The trouble with naming anything "new" is that in ten years time it's not new any more, and you could end up needing a "new new" method too. -- Steve _______________________________________________ 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/MOAITAIZDIXRIJUAV6EODU25ZCUKWJMA/ Code of Conduct: http://python.org/psf/codeofconduct/
