[Python-ideas] Re: Ability to set precedence of classdict (returned from __prepare__) for a metaclass type

Andrew Barnert wrote: > On Oct 20, 2019, at 03:36, Steve Jorgensen ste...@stevej.name wrote: > And there are multiple PyPI projects that build Django choices on top of > Enum, which > show that the only thing you need is to override __getitem__ to replace its > mapping > behavior with sequence b

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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

[Python-ideas] Re: Extending @ syntax to allow expressions

On 21Oct2019 20:41, Andrew Barnert wrote: On Oct 21, 2019, at 19:53, Cameron Simpson wrote: On 21Oct2019 17:18, Yonatan Zunger wrote: I came across a case which *might* be a use case for a syntax extension, but I'm not sure. Wanted to get feedback from the group. *The extension: *Extend the

[Python-ideas] Re: Extending @ syntax to allow expressions

On Oct 21, 2019, at 19:53, Cameron Simpson wrote: >> On 21Oct2019 17:18, Yonatan Zunger wrote: >> I came across a case which *might* be a use case for a syntax extension, but >> I'm not sure. Wanted to get feedback from the group. >> >> *The extension: *Extend the decorator syntax from >> >>

[Python-ideas] Re: Ability to set precedence of classdict (returned from __prepare__) for a metaclass type

Andrew Barnert wrote: > On Oct 20, 2019, at 03:36, Steve Jorgensen ste...@stevej.name wrote: > Maybe the additional functionality in Enum gets in your way for some reason I > don’t > understand, that doesn’t affect other people who want Django choices. But > otherwise, I > don’t see how it really

[Python-ideas] Re: Extending @ syntax to allow expressions

Steve Jorgensen wrote: > had not thought of that. That actually does work. :) > I would say that means there is no need for a new feature, but would it make > sense for > this idiom to be documented in a PEP or some other easily discoverable place? Sorry. I forgot to quote for context. Random832

[Python-ideas] Re: Extending @ syntax to allow expressions

had not thought of that. That actually does work. :) I would say that means there is no need for a new feature, but would it make sense for this idiom to be documented in a PEP or some other easily discoverable place? ___ Python-ideas mailing list -- p

[Python-ideas] Re: Extending @ syntax to allow expressions

On 21Oct2019 17:18, Yonatan Zunger wrote: I came across a case which *might* be a use case for a syntax extension, but I'm not sure. Wanted to get feedback from the group. *The extension: *Extend the decorator syntax from decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE

[Python-ideas] Re: Extending @ syntax to allow expressions

On Mon, Oct 21, 2019 at 8:21 PM Yonatan Zunger wrote: > > Hey everyone, > > I came across a case which might be a use case for a syntax extension, but > I'm not sure. Wanted to get feedback from the group. [...] > @CronJob('job-name', params...).override('dev', more-params...) > def myFunction(

[Python-ideas] Re: Extending @ syntax to allow expressions

On Mon, Oct 21, 2019, at 22:30, Random832 wrote: > On Mon, Oct 21, 2019, at 22:00, Steve Jorgensen wrote: > > I think some idea like this might be worth proposing. the first idea > > that comes to my mind is to allow the name of a decorator to be an > > fstring using `@'...'` or `@"..."` syntax.

[Python-ideas] Re: Extending @ syntax to allow expressions

On Mon, Oct 21, 2019, at 22:00, Steve Jorgensen wrote: > I think some idea like this might be worth proposing. the first idea > that comes to my mind is to allow the name of a decorator to be an > fstring using `@'...'` or `@"..."` syntax. > > If, for example, you have `method_type = 'class'`, t

[Python-ideas] Re: Extending @ syntax to allow expressions

I think some idea like this might be worth proposing. the first idea that comes to my mind is to allow the name of a decorator to be an fstring using `@'...'` or `@"..."` syntax. If, for example, you have `method_type = 'class'`, then you could decorate a method using `@'{method_type}method'`.

[Python-ideas] Re: Copying a multiple values of a dict to another with a lot easier syntax

I believe you made a mess. For all attribute getting needs, I think operator.attrgetter should suffice. No need to implement it yourself. For attribute setting needs, maybe we can add an equivalent operator.attrsetter. I can see myself using it from time to time. Easy solution, solves the proble

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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 li

[Python-ideas] Re: Copying a multiple values of a dict to another with a lot easier syntax

On 2019-10-21 10:44, gedizgu...@gmail.com wrote: m and n are lists or dicts or enumerates or classes or anything it can be assigned like following: instead of : m.a=n.a; m.b=n.b; m.c=n.c; ... I suggest: a,b,c of m to n ; Interesting.  I also saw this type of redundancy in my code. Instead

[Python-ideas] Extending @ syntax to allow expressions

Hey everyone, I came across a case which *might* be a use case for a syntax extension, but I'm not sure. Wanted to get feedback from the group. *The extension: *Extend the decorator syntax from decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE to decorator ::= "@" expressi

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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 upda

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

The fact ``dict`` is a mutable object makes this PEP very complicated.

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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, a

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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} > > Outside

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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} > > Outside

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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 > >

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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 arr

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

**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 agr

[Python-ideas] Copying a multiple values of a dict to another with a lot easier syntax

m and n are lists or dicts or enumerates or classes or anything it can be assigned like following: instead of : m.a=n.a; m.b=n.b; m.c=n.c; ... I suggest a,b,c of m to n ; I thought of this while writing something in javascript since I love pyhton above everything I can type (even more than nati

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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 the

[Python-ideas] Re: Copying a multiple values of a dict to another with a lot easier syntax

Steve Jorgensen wrote: > gedizgursu＠gmail.com wrote: > > m and n are lists or dicts or enumerates or classes > > or anything it can be assigned like > > following: > > instead of : > > m.a=n.a; > > m.b=n.b; > > m.c=n.c; > > ... > > I suggest: > > a,b,c of m to n ; > > I thought of this while writin

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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 defi

[Python-ideas] Re: Copying a multiple values of a dict to another with a lot easier syntax

On Oct 21, 2019, at 07:44, gedizgu...@gmail.com wrote: > > m and n are lists or dicts or enumerates or classes or anything it can be > assigned like following: Assigning attributes is different from assigning items to a collection like a list or dict. That’s why there are separate syntaxes, and

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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 in

[Python-ideas] Re: Copying a multiple values of a dict to another with a lot easier syntax

gedizgursu＠gmail.com wrote: > m and n are lists or dicts or enumerates or classes or anything it can be > assigned like > following: > instead of : > m.a=n.a; > m.b=n.b; > m.c=n.c; > ... > I suggest: > a,b,c of m to n ; > I thought of this while writing something in javascript since I love pyhton

[Python-ideas] Re: Copying a multiple values of a dict to another with a lot easier syntax

Hi You quite rightly noted that m.a = n.a m.b = m.b m.c = m.c is repetitive. Larger such examples cry out for refactoring. Such can already be done in Python. How about for key in 'a', 'b', 'c': setattr(m, key, getattr(n, key)) If you're doing this a lot, how about a help

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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 ... Iterab

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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 `x`).

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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 a

[Python-ideas] Re: Copying a multiple values of a dict to another with a lot easier syntax

You are introducing new keywords (of & to) which can break a lot of code. Beside that, i dont think any practical use of that statement so -1 from me. On Mon, Oct 21, 2019, 6:01 PM wrote: > m and n are lists or dicts or enumerates or classes or anything it can be > assigned like following: > > i

[Python-ideas] Copying a multiple values of a dict to another with a lot easier syntax

m and n are lists or dicts or enumerates or classes or anything it can be assigned like following: instead of : m.a=n.a; m.b=n.b; m.c=n.c; ... I suggest: a,b,c of m to n ; I thought of this while writing something in javascript since I love pyhton above everything I can type (even more than

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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 beha

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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 expe

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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 ex

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

> >> 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

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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

[Python-ideas] Re: PEP 584: Add + and += operators to the built-in dict class.

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 af

[Python-ideas] Re: Expose _PyGC_generation0 for allowing internal use directly from a CPython extension

He opened https://bugs.python.org/issue38542 It seems like the issue is specific to Python 2.7. Well, see the issue for more details ;-) Victor ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@p

[Python-ideas] Re: Expose Py_TabcheckFlag as other PyAPI_DATA flag.

Eloi opened https://bugs.python.org/issue38543 This issue is specific to Python 2.7. Python 3 no longer has Py_TabcheckFlag. Eloi: hey, you should upgrade to Python 3 and have a look at my PEP 587 "Python Initialization Configuration" ;-) Victor ___ Py

[Python-ideas] Re: Expose Py_TabcheckFlag as other PyAPI_DATA flag.

Hi Victor, yes, you're right. I've already upgraded and I mixed up some patches I used to apply on the old 2.7 branch. Thanks for your feedback. Eloi From: Victor Stinner Sent: Monday, October 21, 2019 13:15 To: GAUDRY Eloi Cc: gu...@python.org ; python-ideas@pyt

[Python-ideas] Re: Expose Py_TabcheckFlag as other PyAPI_DATA flag.

ok, I will. thanks Eloi Gaudry Senior Product Development Engineer, HPC & IT manager Free Field Technologies, part of Hexagon's Manufacturing Intelligence division T: +32 10 495 147 E: eloi.gau...@fft.be [FFT Logo] Free Field Technologies Rue Emil

[Python-ideas] Re: Expose _PyGC_generation0 for allowing internal use directly from a CPython extension

ok, I will. thanks éloi From: Guido van Rossum Sent: Friday, October 18, 2019 20:26 To: GAUDRY Eloi Cc: python-ideas@python.org Subject: Re: [Python-ideas] Expose _PyGC_generation0 for allowing internal use directly from a CPython extension This email is not f

[Python-ideas] Re: Ability to set precedence of classdict (returned from __prepare__) for a metaclass type

Steve Jorgensen wrote: > Oops. Obviously, the above is pseudo-code because I left ('~OTHER~', > 'Something > else') the first assert, and I have (Food, Food) instead of > (Food,) * 4 for the second assert. Possibly some other mistakes as well. Umm, like the fact that I'm testing for colors instea

[Python-ideas] Re: Ability to set precedence of classdict (returned from __prepare__) for a metaclass type

Oops. Obviously, the above is pseudo-code because I left `('~OTHER~', 'Something else')` the first assert, and I have `(Food, Food)` instead of `(Food,) * 4` for the second assert. Possibly some other mistakes as well. ___ Python-ideas mailing list -- p