On Dec 25, 2019, at 14:57, python-ideas--- via Python-ideas
<python-ideas@python.org> wrote:
First, as a side note, you seem to have configured your python-ideas-posting
address with the name “python-ideas” rather than with a name that can be used
to distinguish you from other people. This will make conversations confusing.
> If I can spend my two cents, I think the fact the most of you prefer | is
> because is already how sets works. And IMHO it's a bit illogical, since sets
> also support -. So I do not understand why | was chosen instead of +.
First, what does it matter that sets support -? You could just as well argue
that + for list and str is illogical because int supports - and they don’t. Or
even that + is illogical even for ints because arrays support @ and they don’t.
Just because one analogy holds between two types doesn’t mean every analogy you
can imagine between those types does.
Also, the PEP explicitly says that it’s not ruling out adding all of the set
operators, just deferring it to a separate PEP to be written (and accepted or
rejected) in the future. Given that, if set - (and & and ^) makes anything
illogical, it’s +, not |. (Although really, I think “illogical” is a strange
claim to make for any option here. It’s logical to spell the union of two dicts
the same way you spell the union of two sets; it’s also logical to spell the
concatenation of two dicts the same way you spell the concatenation of two
lists. The question is which one is a more useful analogy, or which one is less
potentially confusing, not which one you can come up with a convoluted way of
declaring illogical if you really try.)
> Furthermore, sets supports < operator, that gives you the false hope that
> sets can be sorted. But it's not.
Sure they can:
>>> a = [{1,2}, {1}]
>>> sorted(a)
[{1}, {1, 2}]
Of course you have to be careful because it’s only a partial order, and sorting
sets that aren’t comparable is usually meaningless. But there’s nothing about <
that demands it be a total order—otherwise, you couldn’t even use it with float.
> So I don't think sets are *not* a good example.
> On the contrary, I feel so **natural** to see dict1 + dict2.
>
> Furthermore, the problem is: what is better for generic functions? Maybe I
> need a generic function that, in its code, do also a sum of input objects.
> Maybe I want to support also dict. In this way writing such function is much
> more hard.
What kind of code needs to “sum” generic things that might be dicts and might
be lists, when they mean such different things? And why doesn’t this code also
need to sum sets? Or other types like tries or something? What’s special and
common to numbers, timediffs, sequences, and dicts. but not sets, tries, and
datetimes?
_______________________________________________
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/UJZU7MS4B4XUS2M5WNRBJIGMHRXIWHXT/
Code of Conduct: http://python.org/psf/codeofconduct/
