On Tue, Dec 3, 2019 at 4:18 AM Steven D'Aprano wrote:

I have some notes in progress for a third revision of the PEP, but I don't think there's anything critical in them, and certainly nothing that need delay asking for a BDFL-Delegate.

Brandt, if you are reading this[1], do you have any objection to me applying to the Steering Council for a BDFL-delegate, or would you prefer me to wait?

Please go ahead and send an email to steering-council@python.org. I jumped the gun a bit and discussed this proposal with the SC when we had some extra time in our meeting. The general sentiment is neutral to positive, provided the operators chosen are | and |=. The sentiment for + and += was distinctly negative. There were also some mumblings about the text of the PEP, but nothing that couldn't be fixed by some editing. I think Nick is going to send you a PR or at least a detailed critique. There was also a question about OrderedDict. I haven't thought much about it; I suppose someone should think about what's the right thing to do here. Maybe ditto for some other common subclasses of dict, like defaultdict. Good luck with the PEP! -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...

On Dec 25, 2019, at 14:57, python-ideas--- via Python-ideas 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?

On Thu, Dec 26, 2019 at 1:12 PM python-ideas--- via Python-ideas
 wrote:
>
> 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.

Except that it DOES make sense in some contexts. People are far too
quick to say that something "makes no sense", implying that there is
no sensible way to interpret it. I've seen plenty of people complain
that you can't add two strings together (ie that concatenation is
fundamentally different from addition), that you can't multiply a list
by an integer, that you can't multiply a string by an integer, that
you can't divide a string by a string, etc, etc, etc. Okay, so Python
only supports the last one for the specific case of paths, but that's
actually only *one* logically defensible interpretation of division
(another being "split on this substring", and I'm sure there are
others).

I'm not asking for Python to support all of those operations, but I do
ask people to be a little more respectful to the notion that these
operations are meaningful.

> 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...

And 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.
>

Mathematically, the subset relationship is a perfectly reasonable
ordering, so it makes perfect sense that the "<" operator be used for
this meaning.

> > 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 ............................

My guess is that you don't have a real name set, so your client has
autogenerated a "real name" from the part of your email address before
the at sign (the "mailbox" portion). If you set an actual name, it'll
come through more readably to everyone else.

ChrisA

On Thu, Dec 26, 2019 at 11:15 PM Marco Sulla via Python-ideas wrote:

Chris Angelico wrote:

...

...

Subtracting two lists or two strings has no sense, so the comparison is unfair. Except that it DOES make sense in some contexts.

Source, please.

Pike v8.1 release 13 running Hilfe v3.5 (Incremental Pike Frontend)

"abc, def, ghi" - ", "; (1) Result: "abcdefghi" ({1, 4, 2, 8, 5, 7}) - ({2, 4}); (2) Result: ({ /* 4 elements */ 1, 8, 5, 7 })

In the case of arrays/lists, subtraction is defined as "remove each of these elements, as many times as it comes up" (kinda like set difference, but retaining order). In the case of strings, it's "remove this substring any time it occurs". I'm not saying that Python needs these features, but they DO make sense in the contexts that make use of them. They are not nonsensical operations.

...

People are far too quick to say that something "makes no sense", implying that there is no sensible way to interpret it.

"There's preferably only one obvious way to do it", no?

That's an argument for not incorporating them into Python. It's not stating that they "make no sense".

...

I've seen plenty of people complain that you can't add two strings together (ie that concatenation is fundamentally different from addition), that you can't multiply a list by an integer, that you can't multiply a string by an integer, that you can't divide a string by a string, etc, etc, etc.

Well, they are wrong :D They want funny and lazy operators? Suggest them numpy. numpy transform Python in the "language" Matlab. And I've seen numpy coders that used ~ also for simple integers... Really funny results. Usually they are scientists, and programming is boring for them.

This is the Blub Paradox in action. You understand adding strings together and therefore it makes sense; but subtracting strings makes no sense, because it doesn't fit in your mind. In reality, both operations are equally plausible.

...

that's actually only one logically defensible interpretation of division (another being "split on this substring", and I'm sure there are others)

No. There is the split function. It's more typical that you forgot to transform the strings, that you probably get from a file, to numbers.

Again, that's a justification for not including it in Python, but it does NOT mean that the operation is nonsensical.

...

I do ask people to be a little more respectful to the notion that these operations are meaningful.

.....respectful? I presented my opinion. You are free to agree or not. I've not swore of split on the floor :D

When your opinion is that an operation "has no sense", that's not respectful.

...

Mathematically, the subset relationship is a perfectly reasonable ordering, so it makes perfect sense that the "<" operator be used for this meaning.

Mathematically, the operator is ⊂. "<" operator is used for comparison, and it's vital for sorting. And sorting sets makes no sense.

Once again, you assert this. Do you have proof that it absolutely makes NO SENSE in any context, or just that you don't see value in it? If you're just presenting your opinion, then present it as an opinion, not as a scoffing dismissal. ChrisA

On Dec 26, 2019, at 04:15, Marco Sulla via Python-ideas wrote:

Mathematically,

Whenever someone tries to argue that “Mathematically, this doesn’t make sense” it ends up isomorphic to an argument that they really would have enjoyed one more semester of math classes as an undergrad but for whatever reason didn’t take it.

the operator is ⊂. "<" operator is used for comparison, and it's vital for sorting.

Yes. It’s the defining operation for the partial order in a poset (partially ordered set). And when studying posets generically, you always spell the operation <. And sorting is a concept on posets, not on integers or any other specific poset. (Sometimes you spell it with the bent curvy < instead of the normal one—but in that case, it’s the bent curvy one that’s vital for sorting.) And containment—the poset formed by a set of sets and the subset relation—is usually the very next example they teach you after the less than operation on integers. In fact, this isn’t just _a_ partial order, but the canonical one: everything else is defined by composing containment orders, taking sub-posets of them, or finding isomorphisms to them (or doing the same with posets recursively defined that way). This works because every partial order is isomorphic to a containment order; that’s one of the first proofs you do, and it’s dead simple. (It’s similar to using permutations in group theory.)

And sorting sets makes no sense.

Well, then all of order theory is wrong. Worse, what do you think does make sense to sort? Natural numbers? Not if any of the usual constructions of the naturals actually works. Briefly: Define zero as {}, succ(n) as n U {n}, and N as the infinite set generated by zero and succ(n) for any other member. Define n

You have not ⊂ on your keyboard? Well.... sorry, you have to use a function :D

Why? I don’t have the raised x character on my keyboard either, and I’m quite happy to spell multiplication with * instead of with a named function or method. And likewise / for division, & for and, and so on.

I'm not against operator overloading, on the contrary. But "<" was clearly chosen only because is graphically similar to ⊂, without thinking about the consequences.

You’ve got it backward. Historically, the subset symbol is a C squashed to look graphically similar to a < (or actually a reversed version of a reversed C squashed to look graphically similar to >), and Russell, who chose that out of the many different popular 19th century spellings, certainly was thinking about the consequences. It’s true that in Python—unlike in set theory—we don’t usually deal with sets of sets (in fact, we can’t, unless we use frozenset), but if you want to abandon the “mathematically” and talk about whether sorting makes sense for Python sets (after all, practicality beats purity), the fact that sorted works on sets and on iterables of sets means that yes, it does. Python’s set.__lt__ makes a perfectly good partial order.

On Dec 26, 2019, at 11:32, Marco Sulla via Python-ideas wrote:

Andrew Barnert wrote:

...

...

the operator is ⊂. "<" operator is used for comparison, and it's vital for sorting. Yes. It’s the defining operation for the partial order in a poset (partially ordered set). And when studying posets generically, you always spell the operation <.

Nope.

Usually, you define the operation <=.

I didn’t want to get into that, because I assumed you weren’t going to argue that <= makes sense for sets but < doesn’t (especially given that a

And posets requires that

set1 <= set1 == True

and this is true. Unluckily, sort operations in Python requires and uses **only** `__lt__()`. And

set1 < set1 == False

Sure, just like with int.