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, m
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 tr
Several requests for a specific use case. This is something I have been working
on just to practice getting a deeper understanding of Python metaprogramming,
so whether this is something that someone should be trying to do is, of course,
a matter of opinion.
The idea is to use a class as a sing
Steve Jorgensen wrote:
> I'm not sure what the best way to deal with this would be, but my first
> thought is to
> maybe have a property that can be set on the metaclass type such as
> metacls.relictant_classdict = True.
Oops. Typo. That should say `metacls.reluctant_classdict = True`.
__
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 +
> That said, though, I'm not sure that this was even what you were asking
about :)
It would be significantly more helpful if the OP had an example for the
specific case where they wanted contextually defined variables to take
priority over the classdict, and explained _why_ this behavior might be
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 Sun, Oct 20, 2019 at 1:58 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 f
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 classdict raises `KeyError`.
There is at least one case i
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 3:18 AM Victor Stinner wrote:
> If possible, please try to read the whole PEP before replying. I would
> prefer to avoid knee-jerk reactions :-) The backward compatibility is
> complex topic where things are not black or white: it's more a
> grayscale.
The proposal seems
Hi Victor,
I think this is a nice idea, but I do wonder how this would
be used in practice:
The problem is that Python projects
typically use lots of 3rd party modules and if a few decide
to use/rely on the feature, this may create a situation where
packages then compete over which compatibility
15 matches
Mail list logo
