Using `dct -= key` is WAAAYY too cryptic. A method would be okay, but since that is just `dct.pop(key, None)` without the second argument, it's not worth the trouble.
-1 On Thu, Apr 28, 2022, 12:03 PM Zach Victor <zmvic...@gmail.com> wrote: > Good points, Antoine! > > The intent is to mutate the dictionary with no side effects if a key > exists — and without the extra code that comes along with a control > structure, a try except, or positing a None to throw away. > > For me, pop() says "give me something." Since the intent is to mutate the > dictionary only and not "get something," I'd prefer (i) not to use a > function that returns a value and (ii) not to specify a return value None > just so that it can be thrown away. Perhaps if pop()'s default return value > were None—as it is with, say, get()—I would use pop() as you describe. But > pop() doesn't have a default value unless you give it one, and pop() always > returns a value. > > Where does this land with PEP 20? I think the use of pop() as you suggest > lands on the implicit side of things and is not as readable: the reader has > to ask, "what are we doing with the default value? Oh. Nothing. It's to > delete a dict entry." However, pop() with the default value of None is > practical, and practicality does beat purity. > > I agree that operator overloading needs to be consistent and easy to > understand, and in that regard -= with the dict key probably does not > withstand the PEP 20 tests. Furthermore, in support of your point, the > language has moved in the direction of set operations between dicts using > operators: for example, + for union of dicts. To satisfy set- and key-based > operations, one could overload the augmented arithmetic assignment > operators so that -= with a string would delete the entry with a matching > key, while -= with a dict would delete the entry with a matching key and > value. Again, that may be too recherché or hard-to-explain (cf PEP 20). > > Perhaps, then, it would be best to leave dict alone and just overload > operators in subclasses for specific uses! > _______________________________________________ > 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/ICUUGL7DABI3VTL4GDSNVOM7D3HEO467/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/ZKRCW2ZPKKZW6TLV7SHLK4CJRJPBDB3N/ Code of Conduct: http://python.org/psf/codeofconduct/
