On Fri, Dec 27, 2019 at 02:16:43PM +0000, Jonathan Fine wrote:
> Summary: dict.update(self, other) corresponds to 'merge-right'. Perhaps add
> dict.gapfill(self, other), which corresponds to 'merge-left'.
What does "merge-right" mean to you? When I am driving my car, and I see
a sign "merge right", that means:
- If I am in the right-hand lane, I don't have to do anything
(except watch out for other drivers merging into me) since I'm
already in the right-hand lane.
- If I am in the left-hand lane, I have to merge into the right-hand
lane: I move from the left into the right.
In the case of `d1.update(d2)` the update method moves (actually copies)
keys:values from the right (d2) into the left (d1), which to me is
"merge left".
> This post defines dict.gapfill
I don't understand the connection between the name "gapfill" and any
sort of merge or update operation. To me, "filling a gap" means spraying
expanding foam into a hole, or using a spatula or similar tool to spread
filler into a hole. In both cases, the critical thing is the gapfilling
is unstructured. You just force in some goop, which spreads out into all
the nooks and crannies in a uniform, undifferentiated, manner.
That doesn't seem like a good analogy to a merge/update to me.
> PEP 584 suggests adding a merge operator (to be denoted by '|' or '+') to
> dictionaries, and a corresponding augmented assignment operator (to be
> denoted by '|=' or '+='). The main purpose of this post is to remind
> ourselves that there are both merge-left and merge-right operators, and to
> begin to discuss the consequences.
The PEP covers merges in both directions: "last seen wins" and "first
seen wins". I'm not really sure you're adding anything new here.
> Perhaps Off Topic: There is already a road sign for 'merge left'. See the
> following URL for a discussion of usual 'W4-2' sign for this operation, and
> how it can cause confusion. And how a "small but critical" change to the
> sign reduced confusion, in a backwards compatible way.
I see no evidence given that it reduced confusion. I see only the
*claim* that adding some dotted lines to the confusing graph was
"elegant, simple and additive", but no evidence that it reduced
confusion at all.
The article goes on to explain why the W4 "merge" sign is confusing to
so many people (it violates the conventions used by other signs) and
suggests some alternatives.
But yes, this is off topic. Python is a text-based programming language,
not an icon-based language. We don't have to use icons to hint at the
direction of merging, we can use words or order of operands to do so.
For example, in the PEP, I discuss how you can merge d2 into (a copy
of) d1:
new = d1 + d2 # last seen wins, so d2 merges into a copy of d1
or merge d1 into d2, by just changing the order of operands:
new = d2 + d1
> First, it's my opinion that dict.gapfill(self, other) will be useful when
> we're given say some command line values, and we wish to augment this with
> default values.
The usual way we do that is by starting with the default values, and
updating them with the more specific values:
settings = system_defaults.copy()
settings.update(user_defaults)
or using the proposed `|` or `+` operator:
settings = system_defaults | user_defaults
With your "gapfill" method it would be:
settings = user_defaults.copy()
settings.gapfill(system_defaults) # updates only with new keys
This isn't really more expressive that the other way. It's just swapping
the order of operands.
> Second, it's my opinion that dict.gapfill(self, other) is
> in some cases a useful alternative for a dict merge operator (whether it
> uses '|' or '+' as its symbol). For evidence see
> https://github.com/jpadilla/pyjwt/blob/master/jwt/utils.py#L71-L81
What am I looking at? The "merge_dict" function? I think you need to
look at it a bit more closely, because it does the same "last value seen
wins" semantics of dict.update and the proposed operator, *not* the
"first seen value wins" of your gapfill method.
(The function, as defined, also makes a dubious design choice in that
sometimes it returns a copy of its arguments and sometimes it doesn't.)
[...]
> Fifth and finally. In our context, it is my opinion that merge-left and
> merge-right don't clearly communicate the differing semantics.
We can agree on that.
--
Steven
_______________________________________________
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/MKFVGTFKHYBILBHC6EW33SUKHPO4WVUE/
Code of Conduct: http://python.org/psf/codeofconduct/
