Thanks for your response Serhiy.
> Yes, but this is a different thing. You must to implement new __or__ in a
> subclass to make the behavior of d1 | d2 be different from {**d1, **d2}.
Really? I'm sorry, but this doesn't feel like a real argument to me.
There was no clear compatible path before. Now there is. It works by default,
returning a dict for dict subclasses. If you want to change the return type (or
do something else), you do have to do a little work. Same for every other
overridden thing in any other subclass.
Besides, our argument was just the opposite: "you can't implement anything in a
subclass to make the type of {**d1, **d2} be different".
Now that we've provided a way, it's a problem because you have to define custom
behavior (if you want it)?
> you want an operation for merging OrderedDict, defaultdict, etc and add
> dict.__or__ just for symmetry, even if it is not actually necessary for dicts.
Except that now every dict subclass gets this for free. And now everything
quacks alike.
Are you really suggesting that it would make more sense to implement this for
all subclasses, but not dict itself? I don't think you are, but it sure sounds
like it.
> Let's take a closer look at these examples.
I appreciate that you've taken the time to go through each one, but please note
that the PEP finishes with:
> The above examples show that sometimes the | operator leads to a clear
> increase in readability... However other examples using the | operator lead
> to long, complex single expressions... As with any other language feature,
> the programmer should use their own judgement about whether | improves their
> code.
We're not suggesting that all of the examples would be better, or even
equivalent with the new code. During the discussions last year, people kept
asking for before-and-after examples. We decided to extract real examples
rather than fabricate toys, so for the purposes of this PEP you can assume that
they stand on their own, void of context.
For example, I considered removing the `globs` example because, like you, I
thought it was uglier. However, I figured that it would be wrong to omit it,
since the goal of the section was to show as many candidates for the operator
that we could trivially find, not "all of the ones that Brandt likes better
with |". :)
I'm not sure that continuing this thread of discussion is very productive. As I
have mentioned before, the huge PEP is roughly:
- 50% responses to arguments.
- 35% examples.
- 10% specification.
- 5% links to prior discussions.
We've addressed anything that we felt needed addressing, and they have been
enough to persuade the necessary decision makers. Many of the points you make
have been responded to in some way or another in this monster of a document. :)
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/RHFTVX7IV7VG3GLEVE4ZWOIHTCB2JQBK/
Code of Conduct: http://python.org/psf/codeofconduct/
