On Wed, Aug 26, 2020 at 12:32:56PM -0400, Ricky Teachey wrote: > On Wed, Aug 26, 2020 at 11:19 AM Steven D'Aprano <st...@pearwood.info> > wrote: > > > On Wed, Aug 26, 2020 at 10:10:34AM -0400, Ricky Teachey wrote: > > > > > But I have to say that I think this latest is a fantastic idea, and when > > > Jonathan presented it to me it was very surprising that I had not seen it > > > presented by anyone else yet. I think it solves a ton of problems, > > > > Such as? > > > > 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__`. > This is a > problem because disagreement over this matter is a large part of the reason > PEP 472-- the spirit of which I support-- has been held up. As I see it, the disagreement comes about from two main areas: - People who want to bake into the language semantics which solve a tiny niche problem ("what if I want to treat keyword:argument pairs as keys?"), making the common use-cases much harder to solve. - And people trying to over-engineer some complicated solution to something that isn't actually a problem: the supposed inconsistency between subscripts and function calls. The disagreement isn't from people arguing about how your class should interpret the keywords. That isn't holding up the PEP. Interpreting the keywords is easy: interpret them however you want. Python doesn't tell you what the keywords mean, it just hands them to your method. > It greatly > alleviates (though not perfectly-- see the end of this message) the > incongruity between how the indexing operator behaves and function calls > behave. As explained by Jonathan Fine, it adds flexibility What flexibility is added that `__getitem__` doesn't already provide? > and smoothes out > the differences the different paradigms of subscript operations: sequences, > and mappings. Won't sequences and mappings still call the same dunder method? > And it opens up opportunities for other paradigms to be > created, the most prominent example of which is type-hint creation > shortcuts, like: > > Vector = Dict[i=float, j=float] That's not a paradigm. That's just an application of the feature. *Type-hints* was a major change to the Python's language paradigm. This is just a (potential) nice syntax that allows a concise but readable type-hint. https://en.wikipedia.org/wiki/Paradigm [...] > > > For example: if this proposal were already in place and PEP 472 were to > > > continue to be held up because of terrorists like me ;) *, one could have > > > written this translation function and PEP-472-ify their classes already: > > > > > > def yay_kwargs(self, *args, **kwargs): > > > return self.__getitem__(args, **kwargs) > > > > You're calling the `__getitem__` dunder with arbitrary keyword > > arguments. Are you the same Ricky Teachey who just suggested that we > > should be free to break code that uses `__getitem__` methods that don't > > obey the intent that they have only a single parameter and no keywords? > > > > I am talking hypothetically-- if this proposal were already in place (which > *includes* passing kwargs to the *new dunder* rather than passing them to > the existing item dunders by default), you could write code like yay_kwargs > today, even if the default way the language behaves did not change. You're suggesting that if subscript keywords were permitted, rather than having the keywords passed directly to `__getitem__` where they are wanted, the interpreter should pass them to another method and then that method could pass them to `__getitem__`. Or we could just pass them directly into `__getitem__`, as requested. How does the interpreter know to call yay_kwargs rather than some other method? > In that universe, if I wrote this: > > class C: > def __getitem__(self, key): > print(key) > > ...and tried to do this: > > >>> C()[a=1] > SomeError > > ...*in that universe*, without PEP 472, the language will STILL, by > default, give an error as it does today (though it probably would no longer > be a SyntaxError). That is a remarkably unenlightening example. There's no sign of what your new method is or what it does. There's an error, but you don't know what it is except it "probably" won't be a syntax error, so you don't even know if this error is detected at compile time or runtime. You say PEP 472 is not accepted, but maybe it is accepted since keyword subscripts are possibly not a syntax error, or maybe they are still a syntax error. Who knows? Not me, that's for sure. I feel like I'm trying to nail jelly to a wall, trying to understand your proposal. Every time I ask a question, it seems to twist and mutate and become something else. And how does this relate to Jonathan's idea of "signature dependent semantics" which you were singing the praises of, but seems to have nothing to do with what you are describing now. [...] > We could make the dunder to accept the target dunder method name as a > parameter. This way there is only a single new dunder, rather than 3. Or we could have no new dunders at all, and just pass the keywords to the appropriate, and existing, `__*item__` methods. I'm going to ignore the business about `__subscript__` because you seem to have backed away from it in a later email, except for one relatively minor point. You proposed this: > No CODE CALLS > 1. q[1] q.__subscript__("__getitem__", 1) > 2. q[1,] q.__subscript__("__getitem__", 1) > 3. q[(1,)] q.__subscript__("__getitem__", 1) But that's not what subscripting does now. If you use `q[1,]` the getitem method gets the tuple (1,), not the int 1. So if you're serious about that, it's a breaking change. py> "abcd"[1] 'b' py> "abcd"[1,] TypeError: string indices must be integers -- 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/F343PGE3WGYD7MRKYRLCQKBNKREZF5NZ/ Code of Conduct: http://python.org/psf/codeofconduct/