On 2020-12-26 21:02, Steven D'Aprano wrote:
On Sat, Dec 26, 2020 at 06:52:46PM -0800, Brendan Barnwell wrote:
On 2020-12-26 18:44, Steven D'Aprano wrote:
>I think if we were designing mapping protocols now, that would be an >excellent idea, but we aren't, we have decades of history from `dict` >behind us. And protocols from dict use `keys()` and getitem. E.g. >update.
What do you mean by "protocols from dict"? What are these protocols? "And protocols from dict use `keys()` and getitem. E.g. update."
If I understand you right, that's not a protocol, that's just the behavior of the dict type specifically. As far as I can tell, it's not even documented behavior, so it doesn't constrain anything.
Yes it is documented:
help(dict.update)
and it was intentionally the inspiration for the behaviour of dict augmented assignment.
I see. It's rather disturbing that that isn't mentioned in the docs on python.org.
If you want to argue it's not a protocol, just an interface, okay, it's an interface. That's a difference that makes no difference.
No, it does make a difference. What you're describing is the interface to a single existing type. A protocol is a framework that defines behavior for USER-DEFINED types to hook into, as the descriptor protocol lets you define __get__ or the iterator protocol lets you define __iter__. The fact that dict uses a method with a particular name to do this or that should not constrain the creation of future protocols that define behavior for methods to be defined in user-created classes. That said. . . I'm starting to wonder why not just create a new dunder called __items__ and have dict alias that to .items(). Then the **-unpacking protocol could use that and everything would be fine, right? -- Brendan Barnwell "Do not follow where the path may lead. Go, instead, where there is no path, and leave a trail." --author unknown