[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

> On Dec 26, 2019, at 14:46, Marco Sulla via Python-ideas > wrote: > > David Mertz wrote: >> NaN is an IEEE-854 value, everything you >> mention is precisely identical of floats. >> Is your argument that we need to stop using the '<' operator for floats >> also?! > > Nope, but I simply ignored

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

David Mertz wrote: > NaN is an IEEE-854 value, everything you > mention is precisely identical of floats. > Is your argument that we need to stop using the '<' operator for floats > also?! Nope, but I simply ignored in this case IEEE 754-2019 (that supersedes IEEE 854) and I raised an exception,

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

Really the point about partial order was EXACTLY the thread. If you want to say that floating point numbers are not ordered for exactly the same reason, and in exactly the same way, as sets... well, I guess you can die on that hill. Since NaN is an IEEE-854 value, everything you mention is precis

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

Andrew Barnert wrote: > 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 So you're telling about **strict** partial ordering. I can spend thousand of words, but I think Python can speak for me: ``` (venv) marco@buzz:~/s

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

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

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

Well, Barnert, maybe you didn't understood my irony, so I speak more seriously. This is extremely interesting, but **completely** OT. We are discussing about the operator that potentially could merge in a future two `dict`s. I think this is OT also for the mailing list... but I think you could

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

On Dec 26, 2019, at 10:53, Andrew Barnert wrote: > > 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 t

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

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

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

> 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

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

Random832 wrote: > But sets also support symmetric difference ^, and intersection &. All the > bitwise operators mean the same thing that they do for an integer imagined as > a set of bit > values. The use of - for difference is the odd one out and? __

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

On Wed, Dec 25, 2019, at 21:09, python-ideas--- via Python-ideas wrote: > 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 +. But sets also support symmetric difference ^, and inter

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

Chris Angelico wrote: > > 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

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

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

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

David Mertz wrote: > Set union, however, has a great deal in common with bitwise-or On the contrary, in mathematics there's the concept of direct sum of sets, and the categorical sum, aka disjoint union. They are not union operations, but similar. They have not named them "direct or" and "catego

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

On 12/25/19 10:06 PM, MRAB wrote: On 2019-12-26 02:09, python-ideas--- via Python-ideas wrote: Andrew Barnert wrote: [snip] 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

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

On Wed, Dec 25, 2019, 9:11 PM python-ideas--- via Python-ideas < python-ideas@python.org> wrote: > 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 +. Set union is self-evidently NO

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

On 2019-12-26 02:09, python-ideas--- via Python-ideas wrote: Andrew Barnert wrote: [snip] 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 confu

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

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 al

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

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

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

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 confu

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

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 +. Furthermore, sets supports < operator, that gives you the false hope that se

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

Oh, that’s fair. I don’t think we should update Mapping or MutableMapping. People who want this for their own class can override __or__ and __ror__. On Wed, Dec 4, 2019 at 11:19 Serhiy Storchaka wrote: > 04.12.19 20:18, Guido van Rossum пише: > > On Tue, Dec 3, 2019 at 2:10 AM Serhiy Storchaka >

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

04.12.19 20:18, Guido van Rossum пише: On Tue, Dec 3, 2019 at 2:10 AM Serhiy Storchaka > wrote: And the same question for |. Should `{} | Mapping()` and `{} | []` work? Ditto -- {} | Mapping() should work, but {} | [] should not. set() | Set() falls back to S

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

04.12.19 20:24, Guido van Rossum пише: Your example uses sets -- did you mean {3: 4} instead of {3}? Sorry. Yes, I meant {3: 4}. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org htt

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

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

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

On Tue, Dec 3, 2019 at 2:02 AM Serhiy Storchaka wrote: > I general, I am against this proposition. It makes the language more > complex without adding any benefit. There are already many ways of > merging dicts, including the expression form. It conflicts with Counter. > It can make the code more

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

On Tue, Dec 3, 2019 at 2:10 AM Serhiy Storchaka wrote: > 03.12.19 07:04, Guido van Rossum пише: > > Actually there's no need to optimize the |= operator -- for strings we > > have to optimize += *because* strings are immutable, but for dicts we > > would define |= as essentially an alias for .upd

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

03.12.19 20:51, Brett Cannon пише: On Tue, Dec 3, 2019 at 2:00 AM Serhiy Storchaka > wrote: [SNIP] > ## What about performance? It should be mentioned in the PEP that `dict1 | dict2 | dict3` is less efficient than `{**dict1, **dict2, **dict3}`. ..

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

I think the set operation of dict_keys accepts any iterable by accident. There is an issue for it: https://bugs.python.org/issue38538 On Wed, Dec 4, 2019 at 4:32 PM Serhiy Storchaka wrote: > > 03.12.19 21:04, Andrew Barnert via Python-ideas пише: > > On Dec 3, 2019, at 02:00, Serhiy Storchaka

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

03.12.19 21:04, Andrew Barnert via Python-ideas пише: On Dec 3, 2019, at 02:00, Serhiy Storchaka wrote: What it will return if implement | for dicts? It should be mentioned in the PEP. It should be tested with a preliminary implementation what behavior is possible and more natural. What is

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

> I think the small time difference you noticed is only due to method lookup. I believe it's a bit more than just the Python method lookup, but that makes some difference. Within the C-API, list += other uses list_inplace_concat [1]; whereas list.extend uses _PyList_Extend [2]. They both call list

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

On Dec 3, 2019, at 02:00, Serhiy Storchaka wrote: > > > I argued for | and |= as lesser evil. But there may be a problem. Dict and > dict keys view are interchangeable in the context of some set operations: > "in" checks for existence of the key and iterating yields keys. Currently > both `di

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

On Tue, Dec 3, 2019 at 2:00 AM Serhiy Storchaka wrote: > [SNIP] > > ## What about performance? > > It should be mentioned in the PEP that `dict1 | dict2 | dict3` is less > efficient than `{**dict1, **dict2, **dict3}`. > ... in CPython, but is it guaranteed to be faster in e.g. PyPy? We should be

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

No objection! Brandt > On Dec 3, 2019, at 02:17, Steven D'Aprano wrote: > 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? ___ Python-ideas m

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

I think the small time difference you noticed is only due to method lookup. Le mar. 3 déc. 2019 à 13:57, Kyle Stanley a écrit : > > > Actually there's no need to optimize the |= operator -- for strings we have > > to optimize += *because* strings are immutable, but for dicts we would > > define

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

> Actually there's no need to optimize the |= operator -- for strings we have to optimize += *because* strings are immutable, but for dicts we would define |= as essentially an alias for .update(), just like the relationship between += and .extend() for lists, and then no unnecessary objects would

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

Thanks Guido. 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 Counc

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius On Mon, 2 Dec 2019, 23:55 Guido van Rossum, wrote: > > Also, + is already overloaded enough (numbers, strings, sequences) and we > don't need yet another, different meaning. The | operator should

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

03.12.19 07:04, Guido van Rossum пише: Actually there's no need to optimize the |= operator -- for strings we have to optimize += *because* strings are immutable, but for dicts we would define |= as essentially an alias for .update(), just like the relationship between += and .extend() for list

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

I general, I am against this proposition. It makes the language more complex without adding any benefit. There are already many ways of merging dicts, including the expression form. It conflicts with Counter. It can make the code more errorprone because + or | for dicts will no longer fail imme

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

On Mon, Dec 2, 2019 at 8:39 PM Kyle Stanley wrote: > Also, I think it's worth noting that we can optimize the actual behavior > of the in-place operator under the hood, similar to what is done with > consecutive string concatenations [2]. Of course, the optimization wouldn't > be the same as it i

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

With regard to | vs +, I honestly think the former would be *easier* for beginners than the latter, because: - Having a behavior that is unrelated to other uses of + would arguably be harder to learn, or at least easier to misunderstand when you first see it. - In the CS class world, many students

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

> I don't particularly care about learnability or discoverability in this case -- I don't think beginners should be taught these operators as a major tool in their toolbox (let them use .update()), and for anyone wondering how to do something with a dict without access to the official docs, there's

[Python-ideas] Re: Moving PEP 584 forward (dict + and += operators)

Thanks for the detailed feedback and helpful suggestions, Guido. Steven, I’m currently on my honeymoon through the 16th, and won’t be working on this (or anything). Feel free to address these points while I’m out. When I’m back I’ll be happy to touch base and make a PR, update the implementation