Andrew Barnert wrote: > On Dec 25, 2019, at 14:57, python-ideas--- via Python-ideas > python-ideas@python.org wrote: > > 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.
Subtracting two lists or two strings has no sense, so the comparison is unfair. On the contrary, on sets you can apply union *and* difference. And since union seems the exact contrary of difference, it's illogical that | is used instead of +. That said, the set API at this point is consolidated. My only hope is Python does not make the same errors with `dict` or any other type. > (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 See above... > Of course you have to be careful because it’s only a partial order, and > sorting sets > that aren’t comparable is usually meaningless Indeed, what a coder really need is a isstrictsubset() method, not <. Since set1 < set2 has sense, but sorted(sets) have not. So it was better to have set1.isstrictsubset(set2) and **no** <. But, as I said, the ship was sailed for sets. > What kind of code needs to “sum” generic things that might be dicts and might > be > lists, when they mean such different things? Now I can't think about any practical example. Anyway, generally speaking, Python is full of functions that can be applied to completely different objects, just because the API is identical. If it quacks... > And why doesn’t this code also need to sum sets? Who said it does not need? It will be simply more convoluted. So I hope, again, this does not happen to `dict` too. > What’s special and common to numbers, timediffs, sequences, and dicts. but > not sets, tries, and datetimes? Well, because summing 2 datetimes has no sense? About tries, I don't remember tries in the stdlib. If so, it's OT. > 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. .......I'm not asking to support other operators and I don't really know why you think so. > 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. ............it's python-ideas@***marco.sulla****.e4ward.com ............................ _______________________________________________ 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/3MR4NMJO6SBG3JMGDE4PN74AAKIRAJKW/ Code of Conduct: http://python.org/psf/codeofconduct/
