On 24/10/2019 18:19:27, Andrew Barnert via Python-ideas wrote:
On Oct 23, 2019, at 23:47, Inada Naoki wrote:
But if we use + for dict merging, I think we should add + to set too.
Then the set has `.union()`, `|` and `+` for the same behavior.
I don’t think we really need that. If set and dic
On Oct 23, 2019, at 23:47, Inada Naoki wrote:
>
> But if we use + for dict merging, I think we should add + to set too.
> Then the set has `.union()`, `|` and `+` for the same behavior.
I don’t think we really need that. If set and dict have only a tiny bit of
overlap in their API today (beyond
On 17/10/2019 14:59:13, Anders Hovmöller wrote:
On 17 Oct 2019, at 14:26, Chris Angelico wrote:
On Thu, Oct 17, 2019 at 11:08 PM Anders Hovmöller wrote:
So how can you get a type error when doing
a*b
is the real question. And the answer is now obvious: any time the programmer
thinks
On Wed, Oct 23, 2019 at 11:47 PM Inada Naoki wrote:
> So reusing | to set union is very natural to me.
>
I understand that, and agree -- it made sense to me when set() was
introduced.
But that wasn't my point -- we are not deciding now what operator to use
for set union, we are deciding what op
> no one can tell what either '+' or '|' does in this context without
> guessing, because it does do neither "arithmetic addition", nor
> "concatenation", nor "union set" (or bitwise op, or any other op one could
> come up). '+' is more familiar or '|' might even be completely new for some
> users,
Steven D'Aprano wrote:
> We're talking about an operator to copy-and-update a dict, not invade
> Iraq.
[grin] Fair enough.
In the interim, actually, I realized some semantic downsides of using pipe.
If a user happens to draw an analogy to logical 'or', the 'which one wins'
semantics is differ
On Thu, Oct 24, 2019 at 10:01:28AM -, brian.sk...@gmail.com wrote:
> So: In most cases, uptake will be slow anyways. I'd rather have it be
> a bit slower, and use an operator that will make people think more
> carefully about what it does while they're learning to use it.
o_O
We're talking
Christopher Barker wrote:
> if | is implemented, I'll bet you dollars to donuts that it will get used
> far less than if + were used.
> (though some on this thread would think that's a good thing :-) )
> -CHB
(Non-beginner, |-preferrer)
I think Christopher is correct here, but only to a point. I
On Thu, Oct 24, 2019 at 1:20 AM Christopher Barker wrote:
>
> On Wed, Oct 23, 2019 at 5:42 AM Rhodri James wrote:
>>
> frankly, the | is obscure to most of us. And it started as "bitwise or", and
> evokes the __or__ magic method -- so why are we all convinced that somehow
> it's inextricably li
Jan Greis wrote:
> On 22/10/2019 06:43, Richard Musil wrote:
> > It is not a "concatenation" though, because you lost
> > {"key1": "val1"}
> > in the process. The concatenation is not _just_ "writing something
> > after something", you can do it with anything, but the actual
> > operation, produ
On Wed, Oct 23, 2019 at 1:19 PM Christopher Barker
wrote:
> On Wed, Oct 23, 2019 at 5:42 AM Rhodri James wrote:
>
>> > I'm surprised by that description. I don't think it is just newcomers
>> > who either suggest or prefer plus over pipe, and I don't think that pipe
>> > is "more accurate".
>>
>
Other folks (and I earlier) have explained why we think | is the better choice,
if less obvious.
On 2019-10-22 21:41, Steven D'Aprano wrote:
I think that is patronising to anyone, newbies and experienced
programmers alike, who know and expect that merging dicts with an
operator will have the sa
On Mon, Oct 21, 2019 at 4:49 PM Brandt Bucher
wrote:
> Meitham Jamaa wrote:
> > The fact dict is a mutable object makes this PEP very complicated.
>
no, it doesn't -- a mutable inside a container of any sort has the same
issues:
Yes, that does cause it's confusion, but this proposal doesn't cha
On Wed, Oct 23, 2019 at 5:42 AM Rhodri James wrote:
> > I'm surprised by that description. I don't think it is just newcomers
> > who either suggest or prefer plus over pipe, and I don't think that pipe
> > is "more accurate".
>
> +1 (as one of the non-newcomers who prefers plus)
>
me too.
fran
On 23/10/2019 05:41, Steven D'Aprano wrote:
On Tue, Oct 22, 2019 at 11:39:59AM -0700, Mike Miller wrote:
On 2019-10-18 10:23, Ricky Teachey wrote:
but i'm -0 because i am very concerned it will not be obvious to new
learners, without constantly looking it up, whether adding two mappings
togethe
On Wed, Oct 23, 2019 at 7:18 AM Steven D'Aprano wrote:
> On Tue, Oct 22, 2019 at 11:39:59AM -0700, Mike Miller wrote:
> >
> > On 2019-10-18 10:23, Ricky Teachey wrote:
> > >but i'm -0 because i am very concerned it will not be obvious to new
> > >learners, without constantly looking it up, whethe
On Tue, Oct 22, 2019 at 11:39:59AM -0700, Mike Miller wrote:
>
> On 2019-10-18 10:23, Ricky Teachey wrote:
> >but i'm -0 because i am very concerned it will not be obvious to new
> >learners, without constantly looking it up, whether adding two mappings
> >together would either:
>
> The big tra
I'm not crazy about advertising APIs this way ("did you mean ..."), and
even if we would eventually decide to do this, I'm not sure that dict+dict
is the place to start. (Okay, we already started, with "print x" saying
"Did you mean print(x)?" -- but that shows how rare this should be IMO.)
Anyway
On Oct 22, 2019, at 11:39, Mike Miller wrote:
>
> Had an idea, why not choose the more accurate syntax: |, |= after all? Then,
> to help newcomers and forgetful pros a custom error message is implemented
> for +, +=. In pseudo C/Python, something like this:
>
>class dict:
>
>def
I really like this idea. Once you've already decided to raise an
exception, does it really cost much to try to raise a more helpful one?
And helpful exception messages make programming a lot less painful, and a
lot more of a joy.
On Tue, Oct 22, 2019 at 2:43 PM Mike Miller
wrote:
>
> On 2019-10
On 2019-10-18 10:23, Ricky Teachey wrote:
but i'm -0 because i am very concerned it will not be obvious to new learners,
without constantly looking it up, whether adding two mappings together would either:
The big trade off I'm gathering from this mega-thread is that the |, |=
operators are m
On 22/10/2019 06:43, Richard Musil wrote:
It is not a "concatenation" though, because you lost {"key1": "val1"}
in the process. The concatenation is not _just_ "writing something
after something", you can do it with anything, but the actual
operation, producing the result.
My point is that if
On Tue, Oct 22, 2019 at 12:05 AM Jan Greis wrote:
> On 21/10/2019 21:14, Dominik Vilsmeier wrote:
> > Exactly, so the dict "+" behavior would match the set "|" behavior,
> preserving the keys. But how many users will be concerned about whether the
> keys are going to be preserved? I guess almost
On Tue, Oct 22, 2019 at 12:03:02AM +0200, Jan Greis wrote:
> There's one reason for + which I feel is being missed (though I think
> someone may have briefly mentioned it last time this topic was brought
> up): If we look at the behaviour of dict literals, adding two dicts
> actually behaves li
Meitham Jamaa wrote:
> The fact dict is a mutable object makes this PEP very complicated.
> Let's say we have this example:
> x = {'a': 1, 'b': 2, 'c': {'c': 3}}
> y = {'d': 4, 'c': {'c': 5}}
> If we were to merge the two dicts together, such as:
> x.update(y)
> Then we expect y to have been upda
The fact ``dict`` is a mutable object makes this PEP very complicated.
On 21/10/2019 21:14, Dominik Vilsmeier wrote:
Exactly, so the dict "+" behavior would match the set "|" behavior, preserving the keys. But how many users will be
concerned about whether the keys are going to be preserved? I guess almost everybody will want to know what happens with the values, a
Steven D'Aprano wrote:
> On Sat, Oct 19, 2019 at 02:02:43PM -0400, David Mertz wrote:
> > The plus operation on two dictionaries feels far more
> > natural as a
> > vectorised merge, were it to mean anything. E.g., I'd expect
> > {'a': 5, 'b': 4} + {'a': 3, 'b': 1}
> > {'a': 8, 'b': 5}
> > Outside
Steven D'Aprano wrote:
> On Sat, Oct 19, 2019 at 02:02:43PM -0400, David Mertz wrote:
> > The plus operation on two dictionaries feels far more
> > natural as a
> > vectorised merge, were it to mean anything. E.g., I'd expect
> > {'a': 5, 'b': 4} + {'a': 3, 'b': 1}
> > {'a': 8, 'b': 5}
> > Outside
Steven D'Aprano wrote:
> On Sun, Oct 20, 2019 at 11:29:54PM -, Dominik Vilsmeier wrote:
> > The question is, why would someone who has experience
> > with adding
> > counters but never felt the need to add dicts, assume that this
> > behavior is specialized in Counter and not inherited by
> >
Steven D'Aprano wrote:
> On Sun, Oct 20, 2019 at 11:48:10PM -, Dominik Vilsmeier wrote:
> > Regarding "|" operator, I think a drawback is the
> > resemblance with
> > "or" (after all it's associated with "__or__") so people might assume
> > behavior similar to x or y where x takes precedence
Agreed -- Anyone who uses numpy a lot might make the same assumption, because
numpy vectorizes. Anybody who doesn't might expect an extension-equivalent:
>>> import numpy as np
>>> a1 = np.arange(2,6)
>>> a2 = np.arange(4,0,-1)
>>> a2
array([4, 3, 2, 1])
>>> a1
array([2, 3, 4, 5])
>>> a1 + a2
arr
**Strongly** disagree. I would anticipate using this feature a LOT, and would
be excited to see it added. (I would love to replace things like "d2 =
d1.copy(); d2.update(d3)" with just "d2 = d1 | d3". In-place "d2 |= d3" is nice
in its terseness, but isn't a huge benefit.) But, I completely agr
On Oct 21, 2019, at 09:29, Steven D'Aprano wrote:
>
> What did you think it was, if it wasn't a
> specialised "sum these values" function?
For what it’s worth, I initially thought it was a general fold function, using
the magic of optional parameters and operator polymorphism to default to the
On Mon, Oct 21, 2019 at 10:25:57AM -0500, Dan Sommers wrote:
> Iterables are ordered collections of values, and outside of
> specialized subclasses, we can't expect that adding the values
> is meaningful or even possible.
Correct. That's why lists, tuples, strings, bytes and even arrays all
defi
On Sun, Oct 20, 2019 at 11:29:54PM -, Dominik Vilsmeier wrote:
> The question is, why would someone who has experience with adding
> counters but never felt the need to add dicts, assume that this
> behavior is specialized in `Counter` and not inherited by `dict`.
I think you might mean in
On 10/21/19 9:51 AM, Steven D'Aprano wrote:
Dicts are a key:value store, not a multiset, and outside of specialised
subclasses like Counter, we can't expect that adding the values is
meaningful or even possible. "Adding the values" is too specialised and
not general enough for dicts ...
Iterab
On Sun, Oct 20, 2019 at 11:48:10PM -, Dominik Vilsmeier wrote:
> Regarding "|" operator, I think a drawback is the resemblance with
> "or" (after all it's associated with "__or__") so people might assume
> behavior similar to `x or y` where `x` takes precedence (for truthy
> values of `x`).
I would use it, and I prefer | for the reasons given by Stephen, MRAB, and
the other proponents.
On Monday, October 21, 2019 at 1:08:32 AM UTC-4, Andrew Barnert via
Python-ideas wrote:
>
> On Oct 20, 2019, at 21:10, Stephen J. Turnbull <
> turnbull...@u.tsukuba.ac.jp > wrote:
> >
> > I'm not a
On Sat, Oct 19, 2019 at 02:02:43PM -0400, David Mertz wrote:
> The plus operation on two dictionaries feels far more natural as a
> vectorised merge, were it to mean anything. E.g., I'd expect
>
> >>> {'a': 5, 'b': 4} + {'a': 3, 'b': 1}
> {'a': 8, 'b': 5}
Outside of Counter when would this beha
On Mon, 21 Oct 2019 at 14:55, David Mertz wrote:
> What is proposed in this PEP is to add a meaning for dct1+dct2 that would be
> well defined, but that would be DIFFERENT from the "one obvious meaning."
For me, what's coming out is that there *is* no "obvious meaning".
People expect different
On 21/10/2019 14:54, David Mertz wrote:
On Mon, Oct 21, 2019, 9:14 AM Rhodri James
The plus operation on two dictionaries feels far more natural as
a vectorised merge, were it to mean anything. E.g., I'd expect
{'a': 5, 'b': 4} + {'a': 3, 'b': 1}
{'a': 8, 'b': 5}
That's only a natural expe
On 10/20/2019 10:08 PM, Andrew Barnert via Python-ideas wrote:
On Oct 20, 2019, at 21:10, Stephen J. Turnbull wrote:
I'm not against having an operator for updating dicts, but "+" is not
it. "|" is fine, though.
It seems like people who don’t really like this feature and don’t plan to use
On Mon, Oct 21, 2019, 9:14 AM Rhodri James
> > The plus operation on two dictionaries feels far more natural as
> a vectorised merge, were it to mean anything. E.g., I'd expect
> >
> {'a': 5, 'b': 4} + {'a': 3, 'b': 1}
> > {'a': 8, 'b': 5}
>
> That's only a natural expectation if you also ex
> >> but i'm -0 because i am very concerned it will not be obvious to new
> >> learners, without constantly looking it up, whether adding two mappings
> >> together would either:
> >
> > When Python first added the dict.update method (I think that was in
> > 1.5?) I could never remember if it kept
On 19/10/2019 19:02, David Mertz wrote:
I am strong -1 on the proposal.
The plus operation on two dictionaries feels far more natural as a
vectorised merge, were it to mean anything. E.g., I'd expect
{'a': 5, 'b': 4} + {'a': 3, 'b': 1}
{'a': 8, 'b': 5}
That's only a natural expectation if
On 20/10/2019 05:52, Inada Naoki wrote:
I think this PEP doesn't include one big disadvantage of the + operator.
If we use + for dict merging, set doesn't support + looks strange
and inconsistent.
As I've said before, set already looks strange and inconsistent to me.
I have some hopes that af
On Oct 20, 2019, at 22:08, Guido van Rossum wrote:
>
> Also note that copy() methods are entirely missing from the ABCs. For
> [Mutable]Sequence and [Mutable]Mapping this is not a coincidence -- there are
> no methods that create new instances. For [Mutable]Set I'm not sure about the
> reason
On Oct 20, 2019, at 21:10, Stephen J. Turnbull
wrote:
>
> I'm not against having an operator for updating dicts, but "+" is not
> it. "|" is fine, though.
It seems like people who don’t really like this feature and don’t plan to use
it mostly really want it to be spelled | if it has to be add
On Sun, Oct 20, 2019 at 9:27 PM Andrew Barnert via Python-ideas <
python-ideas@python.org> wrote:
> Given that MutableSequence and MutableSet do include __iadd__ and __ior__
> respectively, I think the default should obviously be to do the same for
> MutableMapping if we’re adding one of those met
On Oct 20, 2019, at 18:26, Steven D'Aprano wrote:
>> but i'm -0 because i am very concerned it will not be obvious to new
>> learners, without constantly looking it up, whether adding two mappings
>> together would either:
>
> When Python first added the dict.update method (I think that was in
> On 21 Oct 2019, at 00:08, Guido van Rossum wrote:
>
>
> So the choice is really only three way.
>
> 1) Add d1 + d2 and d1 += d2 (using similarity with list + and +=)
> 2) Add d1 | d2 and d1 |= d2 (similar to set | and |=)
> 3) Do nothing
Isn't there 4) add .merged()?
/ Anders
__
On Oct 20, 2019, at 17:34, Steven D'Aprano wrote:
>
>> On Thu, Oct 17, 2019 at 06:07:51PM -0400, Christopher Barker wrote:
>>
>> "
>> Open questions
>> Should these operators be part of the ABC Mapping API?
>> '
>>
>> Absolutely! having the built in mapping NOT be the same as the Mapping API
>>
On Mon, Oct 21, 2019 at 7:07 AM Guido van Rossum wrote:
>
> So the choice is really only three way.
>
> So if we want to cater to what most beginners will know, + and += would be
> the best choice. But if we want to be more future-proof and consistent, | and
> |= are best -- after all dicts are
Steven D'Aprano writes:
> If you learn that + means update, then everything follows from
> that.
"+" doesn't mean "update", though. It means "accumulate".
Consider sets. Except in situations where we have a very limited
vocabulary for operators, such as ASCII-origin programming languages,
we
On 2019-10-21 02:29, Steven D'Aprano wrote:
On Mon, Oct 21, 2019 at 02:02:07AM +0100, MRAB wrote:
In the case of Counter, it supports both + and |.
The proposed operator will replace where there are matching keys. Which
operator of Counter does that? Neither.
That's okay. That's what subcla
On Sun, Oct 20, 2019 at 6:38 PM Steven D'Aprano wrote:
> On Sun, Oct 20, 2019 at 03:06:16PM -0700, Guido van Rossum wrote:
> > So the choice is really only three way.
> >
> > 1) Add d1 + d2 and d1 += d2 (using similarity with list + and +=)
> > 2) Add d1 | d2 and d1 |= d2 (similar to set | and |=
On Sun, Oct 20, 2019 at 03:06:16PM -0700, Guido van Rossum wrote:
> So the choice is really only three way.
>
> 1) Add d1 + d2 and d1 += d2 (using similarity with list + and +=)
> 2) Add d1 | d2 and d1 |= d2 (similar to set | and |=)
> 3) Do nothing
Are you saying a method is a non-starter?
A me
On Mon, Oct 21, 2019 at 02:02:07AM +0100, MRAB wrote:
> In the case of Counter, it supports both + and |.
>
> The proposed operator will replace where there are matching keys. Which
> operator of Counter does that? Neither.
That's okay. That's what subclasses are for: to support specialised
be
On Fri, Oct 18, 2019 at 01:23:42PM -0400, Ricky Teachey wrote:
> i'm a -0 on the PEP.
>
> that being said, I am sure i will probably use the hell out of it. it is
> very convenient syntax for mashing together several mappings:
"I really like this idea, it's great! Let's not do it!"
That's why I
I don't understand the obsession with Counter here. IMO it's a prime
example of sharing implementation through inheritance, an antipattern. It
implements the Mapping (i.e. read-only) interface fine, but while it has
all the methods of the MutableMapping interface, the behavior is
sufficiently diff
On 2019-10-21 01:18, Steven D'Aprano wrote:
On Fri, Oct 18, 2019 at 01:32:55PM -0700, Ethan Furman wrote:
On 10/18/2019 10:25 AM, Steven D'Aprano wrote:
>On Fri, Oct 18, 2019 at 09:17:54AM -0700, Ethan Furman wrote:
>
>>That result just doesn't match up with the '+' operator.
>
>Why not?
Pretty
On Fri, Oct 18, 2019 at 09:17:53AM -0700, Andrew Barnert via Python-ideas wrote:
> I don’t think it’s about the mutating update operation; I think
> everyone can live with the update method there.
[...]
> And I think mutating update just goes along for the ride: if we end up
> adding + in analo
On Thu, Oct 17, 2019 at 06:07:51PM -0400, Christopher Barker wrote:
> "
> Open questions
> Should these operators be part of the ABC Mapping API?
> '
>
> Absolutely! having the built in mapping NOT be the same as the Mapping API
> seems like a really bad idea.
I'm not so sure about that, which i
On Fri, Oct 18, 2019 at 01:32:55PM -0700, Ethan Furman wrote:
> On 10/18/2019 10:25 AM, Steven D'Aprano wrote:
> >On Fri, Oct 18, 2019 at 09:17:54AM -0700, Ethan Furman wrote:
> >
> >>That result just doesn't match up with the '+' operator.
> >
> >Why not?
>
> Pretty sure I answered that question
On Sun, Oct 20, 2019, 6:09 PM Guido van Rossum
> In the end I'm +0.5 on | and |=, +0 on + and +=, and -0 on doing nothing.
>
While my "vote" is and should be much less significant than Guido's, I've
explained why my initial expectation for dict+dict would NOT be the
proposed behavior, but rather
Guido van Rossum wrote:
> So the choice is really only three way.
> 1) Add d1 + d2 and d1 += d2 (using similarity with list + and +=)
> 2) Add d1 | d2 and d1 |= d2 (similar to set | and |=)
> 3) Do nothing
> We're not going to introduce a brand new operator for this purpose, nor are
> we going to u
Guido van Rossum wrote:
> So the choice is really only three way.
> 1) Add d1 + d2 and d1 += d2 (using similarity with list + and +=)
> 2) Add d1 | d2 and d1 |= d2 (similar to set | and |=)
> 3) Do nothing
> We're not going to introduce a brand new operator for this purpose, nor are
> we going to u
Christopher Barker wrote:
> On Sat, Oct 19, 2019 at 3:14 PM Dominik Vilsmeier dominik.vilsme...@gmx.de
> wrote:
> > I like the proposal of adding an operator but I
> > dislike the usage of "+".
> > I'd expect this to do a recursive merge on the dict values for duplicate
> > keys (i.e. adding the va
On Thu, Oct 17, 2019 at 07:48:00AM +, Josh Rosenberg wrote:
[...]
> That's 100% wrong. You're mixing up the unpacking generalizations for dict
> literals with the limitations on keyword arguments to functions. {**d1,
> **d2} is guaranteed to accept dicts with any keys, on any implementation of
I have lots of code of this kind
>>> e = d1.copy(); e.update(d2)
so the addition operator would be most welcome. I congratulate to this PEP!
In fact, I would have wished, and in early programming had assumed, the
`update` method would return the updated array rather than modifying the
existing
On 10/20/2019 03:06 PM, Guido van Rossum wrote:
So the choice is really only three way.
1) Add d1 + d2 and d1 += d2 (using similarity with list + and +=)
2) Add d1 | d2 and d1 |= d2 (similar to set | and |=)
3) Do nothing
In the end I'm +0.5 on | and |=, +0 on + and +=, and -0 on doing not
So the choice is really only three way.
1) Add d1 + d2 and d1 += d2 (using similarity with list + and +=)
2) Add d1 | d2 and d1 |= d2 (similar to set | and |=)
3) Do nothing
We're not going to introduce a brand new operator for this purpose, nor are
we going to use a different existing operator.
On Sat, Oct 19, 2019 at 3:14 PM Dominik Vilsmeier
wrote:
> I like the proposal of adding an operator but I dislike the usage of "+".
> I'd expect this to do a recursive merge on the dict values for duplicate
> keys (i.e. adding the values), even more so since `Counter` (being a
> subclass of dict
Definitely want this functionality. I'd ultimately be happy with any of the top
operator spellings, with tradeoffs:
+ Is more obvious, especially to newcomers, consistent w. seq
| Is more accurate (None or '') --> '', consistent w. set
<< Could learn it easily and say
https://www.python.org/dev/peps/pep-0584/#use-a-merged-method-instead-of-an-operator
In this section, unbound method form is introduced first.
But unbound method is just an option. It is not so important.
The method form is the key part of this proposal.
So please introduce (bound) method first
I think this PEP doesn't include one big disadvantage of the + operator.
If we use + for dict merging, set doesn't support + looks strange
and inconsistent.
And if we add + to set too, set has three way (method, |, and +) to do merging.
Then, all builtin container classes support +. It looks +
I like the proposal of adding an operator but I dislike the usage of "+". I'd
expect this to do a recursive merge on the dict values for duplicate keys (i.e.
adding the values), even more so since `Counter` (being a subclass of dict)
already has that behavior. I understand that "+" is meant as a
I am strong -1 on the proposal.
The plus operation on two dictionaries feels far more natural as a
vectorised merge, were it to mean anything. E.g., I'd expect
>>> {'a': 5, 'b': 4} + {'a': 3, 'b': 1}
{'a': 8, 'b': 5}
However, the hypothetical behavior when different keys are present would
not b
+1 on this, it seems very natural to me.
I don’t mean to downplay the concerns people have, but in my experience
teaching newbies, dictionaries take some time to wrap their heads around
anyway. So yes, they may be confused when + removes data, but they’d be
confused anyway :-)
And it would be les
On Fri, Oct 18, 2019 at 6:39 PM Steven D'Aprano wrote:
> You seem to have come up with a completely unique symbol which has, as
> far as I can tell, never been used before. As far as I can see, neither
> APL nor Perl use it as an operator. I can't see it in Unicode, or as an
> emoticon.
>
What i
On 10/18/2019 10:25 AM, Steven D'Aprano wrote:
On Fri, Oct 18, 2019 at 09:17:54AM -0700, Ethan Furman wrote:
That result just doesn't match up with the '+' operator.
Why not?
Pretty sure I answered that question in my OP. Here it is again since you
conveniently stripped it out:
The prob
On Oct 18, 2019, at 09:33, Steven D'Aprano wrote:
>
> That's certainly true, but only because they will have absolutely no
> clue at all about what |< could possibly mean. "Bitwise-or less-than"
> perhaps, whatever that could mean.
>
> You seem to have come up with a completely unique symbol w
On 2019-10-18 17:31, Andrew Barnert via Python-ideas wrote:
On Oct 18, 2019, at 06:31, Richard Musil wrote:
Technically we can call set union also an "add" operation, yet we use different semantics to
express it, for exactly the same reason, it is not "arithmetic" nor, "concatenation", but
s
On Fri, Oct 18, 2019 at 09:17:54AM -0700, Ethan Furman wrote:
> That result just doesn't match up with the '+' operator.
Why not?
Before answering, please check the PEP to see if your objection has
already been raised.
Addition and the plus operator is flexible enough to be used for
everythin
i'm a -0 on the PEP.
that being said, I am sure i will probably use the hell out of it. it is
very convenient syntax for mashing together several mappings:
# yuck
for d in dict_seq:
my_dict.update(d)
# not much better
{**d1, **d2, **d3}
but i'm -0 because i am very concerned it will not be
On Fri, Oct 18, 2019 at 02:39:41PM +0200, Richard Musil wrote:
> ```
> a = dict(...)
> b = dict(...)
> c = a |< b
> ```
> 2) Anyone finding this in the code, who does not now about the operator,
> will _not_ guess the wrong operation.
That's certainly true, but only because they will have absolu
On Oct 18, 2019, at 06:31, Richard Musil wrote:
>
> Technically we can call set union also an "add" operation, yet we use
> different semantics to express it, for exactly the same reason, it is not
> "arithmetic" nor, "concatenation", but something different.
Set union had analogies to two dif
On 10/16/2019 10:35 PM, Brandt Bucher wrote:
At long last, Steven D'Aprano and I have pushed a second draft of PEP 584
(dictionary addition):
Please let us know what you think – we'd love to hear any *new* feedback that
hasn't yet been addressed in the PEP or the related discussions it link
On Oct 18, 2019, at 06:49, Paul Moore wrote:
>
> IMO, debating the "meaning" of addition, and whether the + operator is
> appropriate here, is not the key question. The real questions for me
> are whether the update operation is used frequently enough to require
> an additional way of spelling it
On 18/10/2019 15:43, Anders Hovmöller wrote:
On 18 Oct 2019, at 15:58, Brandt Bucher wrote:
Basically the whole bottom quarter of the PEP!
https://www.python.org/dev/peps/pep-0584/#examples-of-candidates-for-the-dict-merging-operator
The examples would make more sense if the "before" pictu
> On 18 Oct 2019, at 15:58, Brandt Bucher wrote:
>
> Paul Moore wrote:
>> All of the above is just my subjective opinion. Objective information is
>> likely to only be available by someone looking at a body of real world code
>> and demonstrating what difference the proposed operator would m
On Fri, 18 Oct 2019 at 14:57, Brandt Bucher wrote:
>
> Paul Moore wrote:
> > All of the above is just my subjective opinion. Objective information is
> > likely to only be available by someone looking at a body of real world code
> > and demonstrating what difference the proposed operator would
Paul Moore wrote:
> All of the above is just my subjective opinion. Objective information is
> likely to only be available by someone looking at a body of real world code
> and demonstrating what difference the proposed operator would make to it
> (maybe someone did that already - I've not been
On Fri, 18 Oct 2019 at 14:33, Richard Musil wrote:
> I have no problem with any example you mentioned above, yet I consider
> proposed meaning for '+' symbol in this PEP context fundamentally different
> from either "arithmetic" or "concatenation" meaning, used in the previous
> examples, becau
On Fri, Oct 18, 2019 at 2:49 PM Chris Angelico wrote:
> On Fri, Oct 18, 2019 at 11:41 PM Richard Musil
> wrote:
> >
> > I know this has been somewhat addressed in PEP, but I simply cannot see,
> how adding another ambiguity to the '+' symbol, can be better, because the
> "familiarity" of '+' (wh
On Fri, Oct 18, 2019 at 11:41 PM Richard Musil wrote:
>
> I know this has been somewhat addressed in PEP, but I simply cannot see, how
> adding another ambiguity to the '+' symbol, can be better, because the
> "familiarity" of '+' (which seems to me being an argument in the PEP) just
> hides th
On Thu, Oct 17, 2019 at 7:35 AM Brandt Bucher
wrote:
> Please let us know what you think – we'd love to hear any *new* feedback
> that hasn't yet been addressed in the PEP or the related discussions it
> links to! We plan on updating the PEP at least once more before review.
I, personally, do n
Anders Hovmöller wrote:
> It would have been better with a dedicated concat operator I think but just a
> little bit better.
Interesting little side note, for anyone who doesn't already know: at the C
level, Python objects have two ways of implementing addition and
multiplication. The first is
> On 17 Oct 2019, at 22:44, Steven D'Aprano wrote:
>
> On Thu, Oct 17, 2019 at 01:42:54PM +0200, Anders Hovmöller wrote:
>
>> The multiply a list/string thing is a big mistake imo. You almost
>> never use it so the cost of not having it is almost nothing while the
>> cost of having type err
1 - 100 of 126 matches
Mail list logo