Andras Tantos wrote > > Thanks for picking up on this thread, I almost given up hope that > anyone would be interested. Then it suddenly blew up :)!
to thank all who expressed interest and support. (Andras means 'blew up' in a good way!) And I thank you, Andras. It's nice to be appreciated. I now have more confidence that this discussion will result in changes to Python that will help some users, and hinder none. I'll now turn to next steps. First, something that I have a special responsibility for. Then some technical remarks, on opaque and transparent use of keys. Finally, some suggestions for others. MY SPECIAL RESPONSIBILITY ========================= On 16 July I wrote: > I'll now state some goals. > > 1. Define 'o' and Protocol so that NOW gives the semantics you wish for. > 2. Extend Python so that FUTURE give the semantics you wish for. > 3. And the NOW syntax continues to work as expected (without changing 'o' > and Protocol). > 4. And all current use of container[key] continues to work as before. > > I believe that it is possible to achieve these goals. My previous posts to > this discussion outline some of the key ideas. My next step, when I have > time, is to implement and publish general purpose code for the NOW part of > this list of goals. I hope to have this done by the end of this month. It won't be my immediate priority. I'm attending the online TeX Users Group conference next week, and haven't written my talks yet. http://tug.org/tug2020/ TECHNICAL REMARKS =================== Here are some remarks related to this goal which, I hope, will help you. I hope it helps both in your discussions, and in any responsibilities you choose to take on. My remarks concern the coexistence of what I call the opaque and transparent points of view, regarding the syntax >>> d[1, 2, x=3, y=4] A dict accepts any hashable object as a key. >>> class A: __hash__ = lambda self: 0 >>> {A(): 1} {<__main__.A object at 0x7f221087fa90>: 1} My proposal is that >>> d[1, 2, x=3, y=4] = 5 results in the call >>> dict.__setitem__(d, k, 5) where k is a hashable object, perhaps K(1, 2, x=3, y=4) for some new class K. Let's call this an OPAQUE use of k = K(1, 2, x=3, y=4). We don't look into k, and the dict class checks that it is hashable. In some other situations we wish for >>> d[1, 2, x=3, y=4] = 5 to result in a call such as >>>> __setitem__(d, (1, 2), 5, x=3, y=4) where __setitem__ is a function defined in the implementation of D = type(d). I fully support this goal, although not the implementation details in the example above. It is my opinion that this goal is best achieved by making easier TRANSPARENT use of k = K(1, 2, x=3, y=4) Here's how it goes. First we write class D: @wibble def __setitem__(self, val, u, v, x, y): pass # Or do something. Next, we define wibble. It will be a SIGNATURE CHANGING ADAPTER. Those who know how to make decorators will, I hope, have little difficulty in defining wibble to do what is required. For this exercise, assume that k.argv = (1, 2), and k.kwargs = dict(x=3, y=4). The main idea is that each class will make an opaque use of the key, unless it uses a signature changing adapter to enable a transparent use of the key. Thus, by default key use is opaque, but if a class wishes it can make transparent use. Without examples and working code (which I've promised for the end of the month), this might be hard to understand. However this is I hope clear enough for now. SUGGESTIONS FOR OTHERS ======================== Arising out of the discussion, it seems to me there are several different mental models for >>> d[...] = x >>> x = d[...] >>> del d[...] particularly when keyword arguments are allowed in k[...]. I think clarifying the various mental models would be very helpful. By the way, I don't think any one model will be better than all the others, for all purposes. This is particularly true for beginners and experts. And also when there is already an existing mental model, such as in xarray. The implementation of the resulting PEP would require change to user documentation, and in particular to the tutorial. https://docs.python.org/3/ https://docs.python.org/3/tutorial/index.html I think it would be helpful to review the docs, to find some of the places where the docs will need change. Some say that to really understand something, you have to explain it to someone else, who doesn't share your background. I'm sure there are other useful things to do, such as exploring how all this might help users of xarray. But I'm even less qualified to make suggestions in that area. I hope this post is helpful, particularly as I spent an hour writing it, and perhaps a similar time thinking about these matters. I think that's enough for now. When I have some code for you to look at, I'll let you know. -- Jonathan
_______________________________________________ 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/YW3JXKKSNIFII7PDNTYEOKUR3FIAFINW/ Code of Conduct: http://python.org/psf/codeofconduct/
