Oops, meant for the list:
> >>
> >> > Chris seems to accept that sometimes you can use a dict subclass, and
> >> > that my proposal will give some representation of "practical
> >> > experience".
> >>
> >> I said "definitely won't", not "will give some". So, no.
> >
> >
> > Jonathan: Chris A. is
On Fri, Mar 22, 2019 at 07:59:03AM +, Jonathan Fine wrote:
> Steven D'Aprano wrote:
>
> > (For the record, the PEP isn't set in stone in regards to the choice of
> > operator.
>
> Steven: Please say what parts of the PEP you consider to be set in
> stone. This will allow discussion to focus
Python fits well in the mind, because (1) by design it reduces
cognitive load, and (2) it encourages its users to reduce cognitive
load, and (3) we have a culture of reading code, taking pride in our
code. Readability counts.
https://en.wikipedia.org/wiki/Cognitive_load
Steven D'Aprano says that
Steven D'Aprano wrote:
> (For the record, the PEP isn't set in stone in regards to the choice of
> operator.
Steven: Please say what parts of the PEP you consider to be set in
stone. This will allow discussion to focus on essentials rather than
details.
--
Jonathan
On Fri, Mar 22, 2019 at 6:47 PM Jonathan Fine wrote:
>
> Chris Angelico wrote:
>
> > The trouble with that is that you can't always use a dict subclass (or
> > a non-subclass MutableMapping implementation, etc, etc, etc). There
> > are MANY situations in which Python will give you an actual real
On Fri, Mar 22, 2019 at 1:58 PM David Mertz wrote:
>
> On Thu, Mar 21, 2019, 10:15 PM Steven D'Aprano wrote:
>> > Of course I could learn it and teach it, but it will always feel
>> > like a wart in the language.
>>
>> Would that wartness be lessoned if it were spelled | or << instead?
>
> Yes,
Chris Angelico wrote:
> The trouble with that is that you can't always use a dict subclass (or
> a non-subclass MutableMapping implementation, etc, etc, etc). There
> are MANY situations in which Python will give you an actual real dict,
> and it defeats the purpose if you then have to construct
On 2019-03-22 02:40, Dan Sommers wrote:
On 3/21/19 9:19 PM, Christopher Barker wrote:
https://docs.python.org/3.8/library/collections.html has some
examples using collections.Counter, which is clearly described
as being a subclass of dict. Amongst the examples:
c + d # add two counters
On Thu, Mar 21, 2019, 10:15 PM Steven D'Aprano wrote:
> What would be the most useful behaviour for dict "addition" in your
> opinion?
>
Probably what I would use most often was a "lossless" merging in which
duplicate keys resulted in the corresponding value becoming a set
containing all the
On 3/21/19 9:19 PM, Christopher Barker wrote:
https://docs.python.org/3.8/library/collections.html has some
examples using collections.Counter, which is clearly described
as being a subclass of dict. Amongst the examples:
c + d # add two counters together: c[x] + d[x]
That's the +
>
> https://docs.python.org/3.8/library/collections.html has some
> examples using collections.Counter, which is clearly described
> as being a subclass of dict. Amongst the examples:
>
> c + d # add two counters together: c[x] + d[x]
>
> That's the + operator operating on two dicts (don't
On Thu, Mar 21, 2019 at 08:13:01PM -0400, David Mertz wrote:
> On Thu, Mar 21, 2019, 7:48 PM Steven D'Aprano wrote:
[...]
> Nonetheless, if I see `dict1 + dict2` the meaning you intend in the PEP
> does not jump out as the obvious behavior. Nor even as the most useful
> behavior.
What would be
On 3/21/19 6:46 PM, Steven D'Aprano wrote:
Antoine and Serhiy seem to worry that there are existing uses of + which
are currently easy to understand but will become less so if dict.__add__
is added. I respect that worry, even if I doubt that they are correct.
If someone can demonstrate that
On Thu, Mar 21, 2019, 7:48 PM Steven D'Aprano wrote:
> A number of people including Antoine and Serhiy seem to have taken the
> position that merely adding dict.__add__ will make existing code using +
> harder to understand, as you will need to consider not just numeric
> addition and
On Thu, Mar 21, 2019 at 03:10:48PM -0700, Brandt Bucher wrote:
> For anyone interested in "trying it out": if you're not against cloning and
> compiling CPython yourself, here is a PEP 584 C implementation I have PR'd
> against master right now. I'm keeping it in sync with the draft PEP as it
>
On Thu, Mar 21, 2019 at 06:02:05PM -0400, David Mertz wrote:
> I dislike the symbol '+' to mean "dictionary merging with value updates." I
> have no objection to, and mildly support, adding '|' with this meaning.
>
> It's not really possible to give "that one example" where + for meeting
> makes
On Fri, Mar 22, 2019 at 3:42 AM Steven D'Aprano wrote:
> And to those who support this PEP, code examples where a dict merge
> operator will help are most welcome!
Since Python examples don't really exist yet, I'm reaching for another
language that DOES have this feature. Pike's mappings
I dislike the symbol '+' to mean "dictionary merging with value updates." I
have no objection to, and mildly support, adding '|' with this meaning.
It's not really possible to give "that one example" where + for meeting
makes code less clear... In my eyes it would be EVERY such use. Every
example
On Fri, Mar 22, 2019 at 8:44 AM Jonathan Fine wrote:
>
> Antoine Pitrou wrote:
> > Note that, if you're able to live with a third-party dependency, the
> > `toolz` package has what you need (and lots of other things too):
> > https://toolz.readthedocs.io/en/latest/api.html#toolz.dicttoolz.merge
>
Antoine Pitrou wrote:
> Note that, if you're able to live with a third-party dependency, the
> `toolz` package has what you need (and lots of other things too):
> https://toolz.readthedocs.io/en/latest/api.html#toolz.dicttoolz.merge
I suggest that the supporters of dict + dict make (and put up on
On Thu, 21 Mar 2019 17:59:41 +
Rhodri James wrote:
>
> >> And to those who support this PEP, code examples where a dict merge
> >> operator will help are most welcome!
>
> I don't use Python often enough to have much to offer, I'm afraid. The
> sort of occasion I would use dict merging
On 21/03/2019 17:59, Rhodri James wrote:
def process():
if time_to_do_thing1():
thing1(base_env + thing1_env_stuff + env_tweaks)
if time_to_do_thing2():
thing2(base_env + thing2_env_stuff + env_tweaks)
...and so on. The current syntax for doing this is a tad
I'd also like to add what I consider to be another point in favor of an
operator:
Throughout all of these related threads, I have seen many typos and
misspellings of current dict merging idioms, from messing up the number of
asterisks in "{**a, **b}", to even Guido(!) accidentally writing the
On 21/03/2019 17:06, Antoine Pitrou wrote:
On Fri, 22 Mar 2019 03:42:00 +1100
Steven D'Aprano wrote:
For those who oppose the + operator, it will help me if you made it
clear whether it is *just* the + symbol you dislike, and would accept
the | operator instead, or whether you hate the whole
On 3/21/19 1:01 PM, Jonathan Fine wrote:
Rémi Lapeyre wrote:
Not matter the notation you end up choosing, I think this code:
https://github.com/jpadilla/pyjwt/blob/master/jwt/utils.py#L71-L81
[...] would greatly benefit from a new merge to merge dicts.
I've looked at the merge_dict defined
Chris Angelico writes:
> ... then, in the interests of productive discussion, could you please
> explain? What is it about dict addition that makes it harder to
> understand than other addition?
Antoine didn't say what dict addition does is harder to understand
than other addition. He said
Brandt Bucher wrote:
> Before:
>
> tmp = keep.copy()
> tmp.update(separate)
> result = function(param=tmp)
> del tmp
> After:
>
> result = f(param=keep+separate)
I'd rewrite this example as:
Before:
fn(param={**keep, **separate})
After:
fn(param=keep + separate)
--
Jonathan
Rémi Lapeyre wrote:
> Not matter the notation you end up choosing, I think this code:
> https://github.com/jpadilla/pyjwt/blob/master/jwt/utils.py#L71-L81
> [...] would greatly benefit from a new merge to merge dicts.
I've looked at the merge_dict defined in this code. It's similar to
def
>
> And to those who support this PEP, code examples where a dict merge
> operator will help are most welcome!
I would definitely include the example you alluded to in the operators
thread:
Before:
tmp = keep.copy()
tmp.update(separate)
result = function(param=tmp)
del tmp
After:
result =
On Thu, 21 Mar 2019 at 17:27, Rémi Lapeyre wrote:
>
> Le 21 mars 2019 à 17:43:31, Steven D'Aprano
> (st...@pearwood.info(mailto:st...@pearwood.info)) a écrit:
>
> > I'd like to make a plea to people:
> >
> > I get it, there is now significant opposition to using the + symbol for
> > this proposed
Steven D'Aprano wrote:
> But if you have *concrete examples* of code that currently is easy to
> understand, but will be harder to understand if we add dict.__add__,
> then please do show me!
# What does this do?
>>> items. update(points)
# And what does this do?
>>> items +=
Le 21 mars 2019 à 17:43:31, Steven D'Aprano
(st...@pearwood.info(mailto:st...@pearwood.info)) a écrit:
> I'd like to make a plea to people:
>
> I get it, there is now significant opposition to using the + symbol for
> this proposed operator. At the time I wrote the first draft of the PEP,
> there
On Fri, 22 Mar 2019 03:42:00 +1100
Steven D'Aprano wrote:
>
> For those who oppose the + operator, it will help me if you made it
> clear whether it is *just* the + symbol you dislike, and would accept
> the | operator instead, or whether you hate the whole operator concept
> regardless of
I'd like to make a plea to people:
I get it, there is now significant opposition to using the + symbol for
this proposed operator. At the time I wrote the first draft of the PEP,
there was virtually no opposition to it, and the | operator had very
little support. This has clearly changed.
At
On Thu, Mar 21, 2019 at 03:16:44PM +0200, Serhiy Storchaka wrote:
> 21.03.19 14:51, Chris Angelico пише:
> >... then, in the interests of productive discussion, could you please
> >explain? What is it about dict addition that makes it harder to
> >understand than other addition?
>
> Currently the
21.03.19 15:24, Chris Angelico пише:
On Fri, Mar 22, 2019 at 12:17 AM Serhiy Storchaka wrote:
21.03.19 14:51, Chris Angelico пише:
... then, in the interests of productive discussion, could you please
explain? What is it about dict addition that makes it harder to
understand than other
On Thu, Mar 21, 2019 at 9:17 AM Serhiy Storchaka
wrote:
> 21.03.19 14:51, Chris Angelico пише:
> > ... then, in the interests of productive discussion, could you please
> > explain? What is it about dict addition that makes it harder to
> > understand than other addition?
>
> Currently the +
On Fri, Mar 22, 2019 at 12:17 AM Serhiy Storchaka wrote:
>
> 21.03.19 14:51, Chris Angelico пише:
> > ... then, in the interests of productive discussion, could you please
> > explain? What is it about dict addition that makes it harder to
> > understand than other addition?
>
> Currently the +
On 21/03/2019 11:34, Antoine Pitrou wrote:
On Wed, 20 Mar 2019 15:46:24 -1000
Christopher Barker
wrote:
This is precisely why I worded my question this way: what has changed
in the last 20 years that make a "+" dict operator more compelling
today than it was? Do we merge dicts much more
21.03.19 14:51, Chris Angelico пише:
... then, in the interests of productive discussion, could you please
explain? What is it about dict addition that makes it harder to
understand than other addition?
Currently the + operator has 2 meanings for builtin types (both are
widely used), after
On Thu, 21 Mar 2019 23:51:12 +1100
Chris Angelico wrote:
> On Thu, Mar 21, 2019 at 11:45 PM Antoine Pitrou wrote:
> >
> > On Thu, 21 Mar 2019 23:35:36 +1100
> > Chris Angelico wrote:
> > > On Thu, Mar 21, 2019 at 10:35 PM Antoine Pitrou
> > > wrote:
> > > > > but it's NOT a new operator,
On Thu, Mar 21, 2019 at 11:45 PM Antoine Pitrou wrote:
>
> On Thu, 21 Mar 2019 23:35:36 +1100
> Chris Angelico wrote:
> > On Thu, Mar 21, 2019 at 10:35 PM Antoine Pitrou wrote:
> > > > but it's NOT a new operator, it is making use of an existing one, and
> > > > sure
> > > > you could guess at
On Thu, 21 Mar 2019 23:35:36 +1100
Chris Angelico wrote:
> On Thu, Mar 21, 2019 at 10:35 PM Antoine Pitrou wrote:
> > > but it's NOT a new operator, it is making use of an existing one, and sure
> > > you could guess at a couple meanings, but the merge one is probably one of
> > > the most
On Thu, Mar 21, 2019 at 10:35 PM Antoine Pitrou wrote:
> > but it's NOT a new operator, it is making use of an existing one, and sure
> > you could guess at a couple meanings, but the merge one is probably one of
> > the most obvious to guess, and one quick test and you know -- I really
> > can't
On Wed, 20 Mar 2019 15:46:24 -1000
Christopher Barker
wrote:
>
> > This is precisely why I worded my question this way: what has changed
> > in the last 20 years that make a "+" dict operator more compelling
> > today than it was? Do we merge dicts much more frequently than we
> > did?
>
>
On Sat, Mar 16, 2019 at 12:39 AM Antoine Pitrou wrote:
> On Sat, 16 Mar 2019 01:41:59 +1100
> Steven D'Aprano wrote:
>
> > Matrix multiplication is a perfect example: adding the @ operator could
> > have been done in Python 0.1 if anyone had thought of it, but it took 15
> > years of
On Sat, 16 Mar 2019 03:44:02 +1100
Steven D'Aprano wrote:
> On Fri, Mar 15, 2019 at 12:34:45PM +0100, Antoine Pitrou wrote:
> > On Thu, 7 Mar 2019 10:58:02 +1100
> > Chris Angelico wrote:
> > >
> > > Lots of words that basically say: Stuff wouldn't be perfectly pure.
> >
> > Chris, please
On Sat, 16 Mar 2019 01:59:07 +1100
Steven D'Aprano wrote:
> On Fri, Mar 15, 2019 at 12:25:22PM +0100, Antoine Pitrou wrote:
>
> > Yeah, well I do think "+=" for lists was a mistake. I *still* have
> > trouble remembering the exact difference between "list +=" and
> > "list.extend" (yes,
On Sat, 16 Mar 2019 01:41:59 +1100
Steven D'Aprano wrote:
>
> Matrix multiplication is a perfect example: adding the @ operator could
> have been done in Python 0.1 if anyone had thought of it, but it took 15
> years of numerical folk "whinging" about the lack until it happened:
Not so
On Sat, Mar 16, 2019 at 09:04:22PM +1300, Greg Ewing wrote:
> Another random thought about this: Mathematicians use addition as a
> metaphor for quite a range of different things, but they tend to only
> use the symbols ∪ and ∩ for actual sets, or things that are very
> set-like. So maybe that's
Another random thought about this: Mathematicians use addition as a
metaphor for quite a range of different things, but they tend to only
use the symbols ∪ and ∩ for actual sets, or things that are very
set-like. So maybe that's an argument for using '+' rather than '|'
for dict merging.
--
Greg
On Fri, Mar 15, 2019 at 11:15 AM Steven D'Aprano
wrote:
> On Fri, Mar 15, 2019 at 10:34:45AM -0700, Brett Cannon wrote:
>
> > Watch the tone please.
>
> Brett, you might have missed my comment about wanting to avoid unhelpful
> arguments about tone, but if you are going to complain about
On Fri, Mar 15, 2019 at 10:34:45AM -0700, Brett Cannon wrote:
> Watch the tone please.
Brett, you might have missed my comment about wanting to avoid unhelpful
arguments about tone, but if you are going to complain about people's
tone, the considerate thing to do is to say what it is that
On Fri, Mar 15, 2019 at 4:36 AM Antoine Pitrou wrote:
> On Thu, 7 Mar 2019 10:58:02 +1100
> Chris Angelico wrote:
> >
> > Lots of words that basically say: Stuff wouldn't be perfectly pure.
>
> Chris, please learn to think twice before contributing what is
> essentially a trivialization of
On 3/15/2019 11:21 AM, Steven D'Aprano wrote:
On Fri, Mar 15, 2019 at 11:54:51AM -0300, Andre Roberge wrote:
On Fri, Mar 15, 2019 at 11:42 AM Steven D'Aprano
wrote:
[snip]
I still remember being told in no uncertain terms by the core devs that
adding a clear() method to lists was a waste of
On Fri, Mar 15, 2019 at 12:34:45PM +0100, Antoine Pitrou wrote:
> On Thu, 7 Mar 2019 10:58:02 +1100
> Chris Angelico wrote:
> >
> > Lots of words that basically say: Stuff wouldn't be perfectly pure.
>
> Chris, please learn to think twice before contributing what is
> essentially a
On Fri, Mar 15, 2019 at 11:54:51AM -0300, Andre Roberge wrote:
> On Fri, Mar 15, 2019 at 11:42 AM Steven D'Aprano
> wrote:
>
> > [snip]
> >
> > I still remember being told in no uncertain terms by the core devs that
> > adding a clear() method to lists was a waste of time because there was
> >
On Fri, Mar 15, 2019 at 12:25:22PM +0100, Antoine Pitrou wrote:
> Yeah, well I do think "+=" for lists was a mistake. I *still* have
> trouble remembering the exact difference between "list +=" and
> "list.extend" (yes, there is one: one accepts more types than the
> other... which one it
On Fri, Mar 15, 2019 at 11:42 AM Steven D'Aprano
wrote:
> [snip]
>
> I still remember being told in no uncertain terms by the core devs that
> adding a clear() method to lists was a waste of time because there was
> already a perfectly good way to spell it with slicing. And then ABCs
> came
On Fri, Mar 15, 2019 at 12:20:21PM +0100, Antoine Pitrou wrote:
> Agreed with this. What is so useful exactly in this new dict operator
> that it hasn't been implemented, say, 20 years ago?
One could say the same thing about every new feature. Since Python 1.5
was so perfect, why add Unicode,
On Thu, 7 Mar 2019 10:58:02 +1100
Chris Angelico wrote:
>
> Lots of words that basically say: Stuff wouldn't be perfectly pure.
Chris, please learn to think twice before contributing what is
essentially a trivialization of someone else's arguments. You're not
doing anything useful here, and
On Mon, 4 Mar 2019 15:57:38 -0800
Guido van Rossum wrote:
>
> > Those two points make me uncomfortable with "+=" strictly behaving
> > like ".update()".
>
> And yet that's how it works for lists. (Note that dict.update() still has
> capabilities beyond +=, since you can also invoke it with
On Mon, 4 Mar 2019 16:02:06 +0100
Stefan Behnel wrote:
> INADA Naoki schrieb am 04.03.19 um 11:15:
> > Why statement is not enough?
>
> I'm not sure I understand why you're asking this, but a statement is "not
> enough" because it's a statement and not an expression.
This is an argument for
On Wed, 6 Mar 2019 00:46:57 +
Josh Rosenberg
wrote:
>
> Overloading + lacks the clear descriptive aspect of update that describes
> the goal of the operation, and contradicts conventions (in Python and
> elsewhere) about how + works (addition or concatenation, and a lot of
> people don't
Just in case I'm not the only one that had a hard time finding the latest
version of this PEP, here it is in the PEPS Repo:
https://github.com/python/peps/blob/master/pep-0584.rst
-CHB
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR(206)
On Sat, Mar 09, 2019 at 11:39:39AM -0800, Stephan Hoyer wrote:
> Would __iadd__ and __isub__ be added to collections.abc.MutableMapping?
No, that will not be part of the PEP. The proposal is only to change
dict itself. If people want to add this to MutableMapping, that could be
considered
Would __iadd__ and __isub__ be added to collections.abc.MutableMapping?
This would be consistent with other infix operations on mutable ABCs, but
could potentially break backwards compatibility for anyone who has defined
a MutableMapping subclass that implements __add__ but not __iadd__.
On Sat,
Thanks to everyone who has contributed to the discussion, I have been
reading all the comments even if I haven't responded.
I'm currently working on an update to the PEP which will, I hope,
improve some of the failings of the current draft.
--
Steven
On Fri, Mar 8, 2019 at 11:25 AM João Matos wrote:
> I've just read your PEP 585 draft and have some questions.
> When you say
> "
>
> Like the merge operator and list concatenation, the difference operator
> requires both operands to be dicts, while the augmented version allows any
> iterable of
Guido van Rossum wrote:
I guess everybody's high school math(s) class was different. I don't
ever recall seeing + and * for boolean OR/AND; we used ∧ and ∨.
Boolean algebra was only touched on briefly in my high school
years. I can't remember exactly what notation was used, but it
definitely
On Fri, Mar 8, 2019 at 3:33 PM Greg Ewing
wrote:
> Guido van Rossum wrote:
> > I guess this explains the behavior of removing results <= 0; it makes
> > sense as multiset subtraction, since in a multiset a negative count
> > makes little sense. (Though the name Counter certainly doesn't seem to
Guido van Rossum wrote:
I guess this explains the behavior of removing results <= 0; it makes
sense as multiset subtraction, since in a multiset a negative count
makes little sense. (Though the name Counter certainly doesn't seem to
imply multiset.)
It doesn't even behave consistently as a
On 2019-03-08 16:55, Guido van Rossum wrote:
[snip]
If we were to use "|" and "&" for dict "union" and "intersection", the
mutual distributive properties will hold.
Since "|" (especially "|=") *is* suitable for "update", I think we
should reserve "+" for some future commutative
On Thu, Mar 7, 2019 at 9:12 PM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Ka-Ping Yee writes:
> > On Wed, Mar 6, 2019 at 4:01 PM Chris Angelico wrote:
>
> > > But adding dictionaries is fundamentally *useful*. It is expressive.
> >
> > It is useful. It's just that +
Hello,
I've just read your PEP 585 draft and have some questions.
When you say
"
Like the merge operator and list concatenation, the difference
operator requires both operands to be dicts, while the augmented
version allows any iterable of keys.
Ka-Ping Yee writes:
> On Wed, Mar 6, 2019 at 4:01 PM Chris Angelico wrote:
> > But adding dictionaries is fundamentally *useful*. It is expressive.
>
> It is useful. It's just that + is the wrong name.
First, let me say that I prefer ?!'s position here, so my bias is made
apparent. I'm
Ka-Ping Yee writes:
> On Wed, Mar 6, 2019 at 4:01 PM Chris Angelico wrote:
> > But adding dictionaries is fundamentally *useful*. It is expressive.
>
> It is useful. It's just that + is the wrong name.
First, let me say that I prefer ?!'s position here, so my bias is made
apparent. I'm
Now, this belongs as a separate PEP, and I probably will write one, but I
propose:
d1 << d2 makes a copy of d1 and merges d2 into it, and when the keys conflict,
d2 takes priority. (Works like copy/update.)
d1 + d2 makes a new dictionary, taking keys from d1 and d2. If d1 and d2 have a
On Wed, Mar 6, 2019 at 4:01 PM Chris Angelico wrote:
> On Thu, Mar 7, 2019 at 10:52 AM Josh Rosenberg
> wrote:
> >
> > Allowing dicts to get involved in + means:
>
> Lots of words that basically say: Stuff wouldn't be perfectly pure.
>
> But adding dictionaries is fundamentally *useful*. It is
On Thu, Mar 7, 2019 at 10:52 AM Josh Rosenberg
wrote:
> The closest I can come to a thorough definition of what + does in Python (and
> most languages) right now is that:
>
> 1. Returns a new thing of the same type (or a shared coerced type for number
> weirdness)
> 2. That combines the
On Wed, Mar 6, 2019 at 10:31 PM Greg Ewing
wrote:
>
> You might as well say that using the + operator on vectors is
> nonsense, because len(v1 + v2) is not in general equal to
> len(v1) + len(v2).
>
> Yet mathematicians are quite happy to talk about "addition"
> of vectors.
>
>
Vectors addition
Ka-Ping Yee wrote:
len(dict1 + dict2) does not equal len(dict1) + len(dict2), so using the
+ operator is nonsense.
You might as well say that using the + operator on vectors is
nonsense, because len(v1 + v2) is not in general equal to
len(v1) + len(v2).
Yet mathematicians are quite happy to
>
> If we use this "literally concat" metaphor, I still think set should have
> `+` as alias to `|` for consistency.
>
I agree.
I think "|" keeps commutativity only because it's minor than `+`.
>
I suppose that's true, fair point.
I guess I would be ok with | no longer always implying
I wrote:
> I wonder, is this behaviour of {'a': 0, 'a': 1} documented (or tested)
> anywhere?
I've answered my own question here:
[Python-ideas] dict literal allows duplicate keys
https://mail.python.org/pipermail/python-ideas/2019-March/055717.html
Finally, Christopher Barker wrote:
> Yes, and
On Wed, Mar 6, 2019 at 10:59 PM Michael Lee wrote:
>
> I think the behavior proposed in the PEP makes sense whether you think of "+"
> as meaning "concatenation" or "merging".
>
> If your instinct is to assume "+" means "concatenation", then it would be
> natural to assume that {"a": 1, "b":
Michael Lee wrote:
> If your instinct is to assume "+" means "concatenation", then it would be
> natural to assume that {"a": 1, "b": 2} + {"c": 3, "b": 4} would be identical
> to {"a": 1, "b": 2, "c": 3, "b": 4} -- literally concat the key-value pairs
> into a new dict.
> But of course, you
On Thu, Mar 7, 2019 at 12:59 AM Michael Lee wrote:
> If your instinct is to assume "+" means "concatenation", then it would be
> natural to assume that {"a": 1, "b": 2} + {"c": 3, "b": 4} would be identical
> to {"a": 1, "b": 2, "c": 3, "b": 4} -- literally concat the key-value pairs
> into a
>
> I strongly agree with Ka-Ping. '+' is intuitively concatenation not
> merging. The behavior is overwhelmingly more similar to the '|' operator in
> sets (whether or not a user happens to know the historical implementation
> overlap).
I think the behavior proposed in the PEP makes sense
Le 06/03/2019 à 13:53, Chris Angelico a écrit :
On Wed, Mar 6, 2019 at 11:18 PM Brice Parent wrote:
The major implication to such a
modification of the Dict.update method, is that when you're using it
with keyword arguments (by opposition to passing another dict/iterable
as positional),
On Wed, Mar 6, 2019 at 11:18 PM Brice Parent wrote:
> The major implication to such a
> modification of the Dict.update method, is that when you're using it
> with keyword arguments (by opposition to passing another dict/iterable
> as positional), you're making a small non-backward compatible
Rhodri James wrote:
> Making assumptions about length where any dictionary
> manipulations are concerned seems unwise to me
I think you're a bit hasty here. Some assumptions are sensible. Suppose
a = len(d1)
b = len(d2)
c = len(d1 + d2) # Using the suggested syntax.
Then we know
Ka-Ping Yee wrote:
>
> len(dict1 + dict2) does not equal len(dict1) + len(dict2), so using the +
> operator is nonsense.
>
> len(dict1 + dict2) cannot even be computed by any expression involving +.
> Using len() to test the semantics of the operation is not arbitrary; the fact
> that the
On Wed, Mar 6, 2019 at 11:52 AM Rhodri James wrote:
> On 06/03/2019 10:29, Ka-Ping Yee wrote:
> > len(dict1 + dict2) does not equal len(dict1) + len(dict2), so using the +
> > operator is nonsense.
>
> I'm sorry, but you're going to have to justify why this identity is
> important. Making
Le 06/03/2019 à 10:50, Rémi Lapeyre a écrit :
Le 05/03/2019 à 23:40, Greg Ewing a écrit :
Steven D'Aprano wrote:
The question is, is [recursive merge] behaviour useful enough and
common enough to be built into dict itself?
I think not. It seems like just one possible way of merging
values
On 06/03/2019 10:29, Ka-Ping Yee wrote:
len(dict1 + dict2) does not equal len(dict1) + len(dict2), so using the +
operator is nonsense.
I'm sorry, but you're going to have to justify why this identity is
important. Making assumptions about length where any dictionary
manipulations are
len(dict1 + dict2) does not equal len(dict1) + len(dict2), so using the +
operator is nonsense.
len(dict1 + dict2) cannot even be computed by any expression involving +.
Using len() to test the semantics of the operation is not arbitrary; the
fact that the sizes do not add is a defining quality
Le 6 mars 2019 à 10:26:15, Brice Parent
(cont...@brice.xyz(mailto:cont...@brice.xyz)) a écrit:
>
> Le 05/03/2019 à 23:40, Greg Ewing a écrit :
> > Steven D'Aprano wrote:
> >> The question is, is [recursive merge] behaviour useful enough and
> > > common enough to be built into dict itself?
> >
>
Le 05/03/2019 à 23:40, Greg Ewing a écrit :
Steven D'Aprano wrote:
The question is, is [recursive merge] behaviour useful enough and
> common enough to be built into dict itself?
I think not. It seems like just one possible way of merging
values out of many. I think it would be better to
INADA Naoki schrieb am 05.03.19 um 08:03:> On Tue, Mar 5, 2019 at 12:02 AM
Stefan Behnel wrote:
>> INADA Naoki schrieb am 04.03.19 um 11:15:
>>> Why statement is not enough?
>>
>> I'm not sure I understand why you're asking this, but a statement is
>> "not enough" because it's a statement and
On Wed, Mar 6, 2019 at 12:08 AM Guido van Rossum wrote:
> On Tue, Mar 5, 2019 at 3:50 PM Josh Rosenberg <
> shadowranger+pythonid...@gmail.com> wrote:
>
>>
>> On Tue, Mar 5, 2019 at 11:16 PM Steven D'Aprano
>> wrote:
>>
>>> On Sun, Mar 03, 2019 at 09:28:30PM -0500, James Lu wrote:
>>>
>>> > I
1 - 100 of 150 matches
Mail list logo
