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 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.
>
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 be
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 = T
> 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 Colors(TokenCo
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 as
On 10/19/2019 07:56 PM, Steve Jorgensen wrote:
When using a custom classdict to implement a DSL or use in the body of a class
definition, from what I can tell by experiment, the classdict takes priority,
and the surrounding context is only referenced if trying to get an item from
the classdic
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 colle
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
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
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 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
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 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
Christopher Barker wrote:
> On Sat, Oct 19, 2019 at 3:14 PM Dominik Vilsmeier [email protected]
> 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
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
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
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 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 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 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
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 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
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 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 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 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
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 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
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 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 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 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 <
[email protected]> 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 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
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 = T
37 matches
Mail list logo
