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
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
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
> 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
>
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
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
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
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,
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
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
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.
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
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,
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
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.)
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:
>
>
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
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
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
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
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
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,
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}
> >
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}
> >
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
**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
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
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
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
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 ...
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
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
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
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
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
> >> 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
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 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
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
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,
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
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
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
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
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?
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
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
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
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
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
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
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
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.
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
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
+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
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
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
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
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
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
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
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
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"
> 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
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,
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 '+'
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
> 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
On Thu, Oct 17, 2019 at 5:33 AM Steven D'Aprano wrote:
> On Thu, Oct 17, 2019 at 08:19:13AM -, Steve Jorgensen wrote:
>
> > Why the need for strictness of type for the operator? I get that it's
> > analogous with the behavior for `list`, but I guess I'm also not sure
> > why that should be
+1
Been waiting a decade+ for this. Too bad it didn't get into 3.8.
Nice work on the PEP.
-Mike
p.s. A another mentioned this existing syntax does allow non-string keys:
>>> d1 = dict(one=1, two=2)
>>> d2 = {'three':3, 4:4}
>>>
>>> {**d1, **d2}
{'one': 1, 'two': 2, 'three': 3, 4:
On Thu, Oct 17, 2019 at 02:08:56PM +0200, Anders Hovmöller wrote:
> Well obviously never with literals. But most cases of multiplication
> aren't with literals. So how can you get a type error when doing
>
> a*b
>
> is the real question.
Actually, the real question is, why are you using such
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 errors propagate beyond the point where they
> happened is big.
I
On Thu, Oct 17, 2019 at 12:41:29AM -0700, Andrew Barnert via Python-ideas wrote:
> Less trivial, but maybe dismissible: it says one of the authors is
> going to write another PEP later to add the full complement of set
> operators to dict.
It says that one of the authors is *interested* in
On Fri, Oct 18, 2019 at 6:06 AM Anders Hovmöller wrote:
>
> > On 17 Oct 2019, at 20:37, Chris Angelico wrote:
> >
> > On Fri, Oct 18, 2019 at 5:25 AM Anders Hovmöller
> > wrote:
> >>
> >> No. The reason I don't know is because this is a hypothetical example. In
> >> real code I would "know"
Steven D'Aprano wrote:
> On Thu, Oct 17, 2019 at 08:19:13AM -, Steve Jorgensen wrote:
> > Why the need for strictness of type for the operator?
> > I get that it's
> > analogous with the behavior for list, but I guess I'm also not sure
> > why that should be strict.
> > (1) Follow the
1 - 100 of 119 matches
Mail list logo
