On Fri, 10 Jul 2020 at 11:54, Jonathan Fine <jfine2358@gmail.com> wrote:
Let's proceed. We continue to use d = Dummy(). Given that >>> key = d[1, 2, 3, a=4, b=5] is allowed, what should we be able to say about the key. Clearly it should be an instance of a class, and there should be a way of creating such an instance without going via d. Let's call the class K (for key).
It is natural to say that >>> key_1 = d[1, 2, 3, a=4, b=5] >>> key_2 = K(1, 2, 3, a=4, b=5) should define two K objects, that are identical.
Accepted.
Once we have designed and implemented the class K, we can achieve many of the benefits of this proposal within existing Python.
There's a flaw in your extrapolation here - see below.
Here goes. First syntax. >>> value = d[K(1, 2, 3, a=4, b=5)] >>> d[K(1, 2, 3, a=4, b=5)] = value
Correct, but *only* if the type of d accepts objects of type K in __getitem__. Your arguments are starting to get tricky to follow because it's not clear if you intend "d" to still be an instance of Dummy. If it is, of course, then d[K(1,2,3, a=4, b=5)] is a very different value than d[1, 2, 3, a=4, b=5]. But maybe you'll patch this up. You've not made an explicitly false statement yet.
Next, the implementation of such K-mappings. Here, K.set and K.get decorators will help. Something like (not tested): class MyMap: @K.adjust_get def __getitem__(self, x1, x2, x3, a, b): pass where K.adjust_get interfaces between the K-object and the definition of __getitem__.
I have no idea how this works, or what it even means.
Aside. Here, not tested, is an implementation of K.adjust_get. class K: @staticmethod def adjust_get(fn): def __getitem__(self, k): return fn(self, *k.argv, **k.kwargs) return __getitem__
I'm still confused. This code is (of course) valid, but I have no idea how you think it would be used. So it doesn't really explain anything, I'm still not clear what you are trying to say.
This introduction of K allows collections to be created, that can be used today with the syntax >>> value = d[K(1, 2, 3, a=4, b=5)] >>> d[K(1, 2, 3, a=4, b=5)] = value
Yes. Obviously. This is the same mechanism slice() uses.
Further, if the K()-less syntax >>> value = d[1, 2, 3, a=4, b=5] >>> d[1, 2, 3, a=4, b=5] = value is added to Python, the existing K-collections could continue to be used, with only a change to the decorator K.adjust_get (and also of course K.adjust_set).
So you're suggesting that like slice, the d[1, 2, 3, a=4, b=5] syntax could be translated into a K-object. Sure. But that doesn't do any good unless classes implement a __getitem__ that recognises and handles objects of type K. And you've not demonstrated how that would happen, unless you were trying to describe that in your adjust_get discussion. So as far as I can see, all you've said is that a syntax like d[1, 2, 3, a=4, b=5] could be translated into indexing with a custom object. Well yes, of course it could. And it probably would be. But that's just describing an implementation approach, it doesn't really give any argument for why we'd *want* to do this, or how (or if) we'd extend existing (built in or user defined) types to understand this syntax. Maybe I'm unusual in that I didn't see any difficulty in implementing this proposal. But as a general principle, I don't tend to worry about "how will this be implemented" when discussing new features. If it's impossible to implement it, that will become obvious in due course :-) What I'm interested in is always "why is this a good idea". And that's where I've yet to see any really compelling use cases in this thread.
I think that is enough for now. I hope it helps some of us, sometimes. And does no harm elsewhere.
It's certainly a useful exposition of how you'd arrive at the implementation mechanism that slice uses, and extend it for this proposal (excluding that confusing adjust_get bit) which may well be useful to some of the readers here. And yes, it certainly doesn't do any harm clarifying it. But I'd recommend focusing on design, not implementation, for now. Paul