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.
On Oct 20, 2019, at 03:36, Steve Jorgensen wrote:
>
> Andrew Barnert wrote:
>> What you’re describing is just enum.Enum, minus half its features, but a
>> sequence
>> instead of a mapping.
>> I’m not sure why you’d ever want this,
>
> Actually, it's a bit different. This is for building a
On 10/19/2019 11:25 PM, Andrew Barnert via Python-ideas wrote:
On Oct 19, 2019, at 22:57, Steve Jorgensen wrote:
The idea is to use a class as a singleton collection of choices where every
choice appears both as an attribute of the class/singleton and as a value/label
pair when treating it
> On 20 Oct 2019, at 12:41, Steve Jorgensen wrote:
>
> Anders Hovmöller wrote:
>> We try to do the same thing in various libraries. We've settled on using
>> existing
>> python and end up with syntax like:
>> class MyForm(Form):
>>field = Field()
>> or in your case
>> class
Anders Hovmöller wrote:
> We try to do the same thing in various libraries. We've settled on using
> existing
> python and end up with syntax like:
> class MyForm(Form):
> field = Field()
> or in your case
> class Colors(TokenContainer):
> red = Token()
> green = Token()
> blue =
Andrew Barnert wrote:
> What you’re describing is just enum.Enum, minus half its features, but a
> sequence
> instead of a mapping.
> I’m not sure why you’d ever want this,
Actually, it's a bit different. This is for building a collection of
value/label pairs where the values are as likely to
Steven D'Aprano wrote:
> I've read the entire thread, and I don't understand what builtins has to
> do with your problem.
Just that, as a workaround, I can have the classdict object raise KeyError for
anything that's a member of builtins so that the builtins are used instead of
being masked.
On Sun, Oct 20, 2019 at 02:56:22AM -, Steve Jorgensen wrote:
> I have been able to at least unmask builtins by having the classdict
> object first try to get a result from `__builtins__` and then fall
> back to itself.
I've read the entire thread, and I don't understand what builtins has
On Oct 19, 2019, at 22:57, Steve Jorgensen wrote:
>
> The idea is to use a class as a singleton collection of choices where every
> choice appears both as an attribute of the class/singleton and as a
> value/label pair when treating it as a sequence.
What you’re describing is just enum.Enum,
We try to do the same thing in various libraries. We've settled on using
existing python and end up with syntax like:
class MyForm(Form):
field = Field()
or in your case
class Colors(TokenContainer):
red = Token()
green = Token()
blue = Token()
(this is using
34 matches
Mail list logo
