Re: [Python-Dev] PEP 572: Assignment Expressions

Tim Peters writes: > Regardless, Guido has already said "as" is DOA (Dead On Arrival) > (illustrating that it's also common enough in English to give a short > name before its long-winded meaning ;-) ). The parens above are a gloss on a well-known acronym for those who have not encountered it

Re: [Python-Dev] PEP 572: Assignment Expressions

On Mon, Apr 23, 2018 at 4:54 PM, Greg Ewing wrote: > Tim Peters wrote: > >> if (diff := x - x_base) and (g := gcd(diff, n)) > 1: >> return g > > > My problem with this is -- how do you read such code out loud? It could be-- "if diff, which we let equal x -

Re: [Python-Dev] PEP 572: Assignment Expressions

On Mon, Apr 23, 2018 at 03:36:10PM -0700, Guido van Rossum wrote: > Using 'as' was debated extensively on python-ideas. I don't like it for > several reasons: [...] For what it is worth, I was one of the original proponents of the "as" syntax, but at this point I am no longer going to argue for

Re: [Python-Dev] PEP 572: Assignment Expressions

[Tim] >> if (diff := x - x_base) and (g := gcd(diff, n)) > 1: >> return g [Greg Ewing ] > My problem with this is -- how do you read such code out loud? In the message in which I first gave that example: if the diff isn't 0 and gcd(diff, n) > 1, return the

Re: [Python-Dev] PEP 572: Assignment Expressions

Sven R. Kunze wrote: if (x - x_base) and gcd(x - x_base, n) > 1: return gcd(x - x_base, n) and have the interpreter handle the optimization, or apply an lru_cache? ;-) Problem is, there's no way to automatically tell whether the expressions involved have side effects that are being

Re: [Python-Dev] PEP 572: Assignment Expressions

Tim Peters wrote: if (diff := x - x_base) and (g := gcd(diff, n)) > 1: return g My problem with this is -- how do you read such code out loud? From my Pascal days I'm used to reading ":=" as "becomes". So this says: "If diff becomes x - base and g becomes gcd(diff, n) is greater

Re: [Python-Dev] PEP 572: Assignment Expressions

On 4/23/2018 1:01 PM, Ethan Furman wrote: On 04/22/2018 10:44 PM, Tim Peters wrote: [Guido] In reality there often are other conditions being applied to the match for which `if expr as name` is inadequate. The simplest would be something like    if ...:       elif (m :=

Re: [Python-Dev] PEP 572: Assignment Expressions

On 2018-04-23, 21:34 GMT, Sven R. Kunze wrote: > Is it just me or since when has the following Python code > fallen out of favor? It isn’t just you. Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 … one of the

Re: [Python-Dev] PEP 572: Assignment Expressions

Using 'as' was debated extensively on python-ideas. I don't like it for several reasons: - the semantics are subtly different from all other uses of 'as' in Python; I'd like to reserve 'as' for "not a plain assignment" - a short word is easier to miss when skimming code than punctuation - most

Re: [Python-Dev] PEP 572: Assignment Expressions

On 04/23/2018 06:04 PM, Tim Peters wrote: > However, against "as" is that its current use in "with" statements > does something quite different: > > with f() as name: > > does not bind the result of `f()` to `name`, but the result of > `f().__enter__()`. Whether that "should be" fatal, I

Re: [Python-Dev] PEP 572: Assignment Expressions

On Apr 23, 2018, at 18:04, Tim Peters wrote: > However, against "as" is that its current use in "with" statements > does something quite different: > >with f() as name: > > does not bind the result of `f()` to `name`, but the result of > `f().__enter__()`. Whether

Re: [Python-Dev] PEP 572: Assignment Expressions

Whereas I find it a deal-breaker for 'as'. On Mon, Apr 23, 2018 at 3:15 PM, Ethan Furman wrote: > On 04/23/2018 03:04 PM, Tim Peters wrote: > >> [Ethan Furman ] >> >>> So I really like being able to make the assignment in the expression, >>> but I >>>

Re: [Python-Dev] PEP 572: Assignment Expressions

On 04/23/2018 03:04 PM, Tim Peters wrote: [Ethan Furman ] So I really like being able to make the assignment in the expression, but I have a really hard time parsing it with the name first. ... On the other hand, if it were using the "as" keyword: if (x - xbase as diff)

Re: [Python-Dev] PEP 572: Assignment Expressions

[Ethan Furman ] > So I really like being able to make the assignment in the expression, but I > have a really hard time parsing it with the name first. > > ... > > On the other hand, if it were using the "as" keyword: > > if (x - xbase as diff) and (gcd(diff, n) as g) > 1: >

Re: [Python-Dev] PEP 572: Assignment Expressions

[Tim] >> Surely you're joking. This is math.gcd(), which is expensive for >> multi-thousand bit integers, and the interpreter knows nothing about >> it. Adding a cache of _any_ kind (LRU or otherwise) would make it >> even slower. [Sven R. Kunze ] > Alright, if that problem is

Re: [Python-Dev] PEP 572: Assignment Expressions

On 23.04.2018 23:19, Barry Warsaw wrote: I also think it effectively solves the switch-statement problem: if (get_response() as answer) == 'yes': do_it() elif answer == 'no': skip_it() elif answer == 'maybe' okay_then() That’s Pythonic enough for jazz! Is it just me or since

Re: [Python-Dev] PEP 572: Assignment Expressions

On Tue, Apr 24, 2018 at 7:25 AM, Sven R. Kunze wrote: > On 23.04.2018 22:37, Chris Angelico wrote: >> >> Ah, are you one of those programmers who writes code once and it's >> instantly perfect? I apologize, I didn't realize I was in the presence >> of a unicorn. > > > Wow,

Re: [Python-Dev] PEP 572: Assignment Expressions

On 23.04.2018 22:37, Chris Angelico wrote: Ah, are you one of those programmers who writes code once and it's instantly perfect? I apologize, I didn't realize I was in the presence of a unicorn. Wow, constructive. Nothing is perfect, but if you don't consider your surroundings when doing

Re: [Python-Dev] PEP 572: Assignment Expressions

On Apr 23, 2018, at 13:01, Ethan Furman wrote: > > On 04/22/2018 10:44 PM, Tim Peters wrote: >> >> >> I find myself warming more to binding expressions the more I keep them >> in mind while writing new code. And I really like the term “binding expressions” because that’s

Re: [Python-Dev] PEP 572: Assignment Expressions

On Tue, Apr 24, 2018 at 6:21 AM, Sven R. Kunze wrote: > On 23.04.2018 19:24, Chris Angelico wrote: >> >> On Tue, Apr 24, 2018 at 3:13 AM, Sven R. Kunze wrote: >>> >>> diff = x - x_base >>> if diff and gcd(diff, n) > 1: >>> return gcd(diff, n) >>> >>> # or

Re: [Python-Dev] PEP 572: Assignment Expressions

On 23.04.2018 19:31, Tim Peters wrote: Surely you're joking. This is math.gcd(), which is expensive for multi-thousand bit integers, and the interpreter knows nothing about it. Adding a cache of _any_ kind (LRU or otherwise) would make it even slower. Alright, if that problem is just about

Re: [Python-Dev] PEP 572: Assignment Expressions

On 23.04.2018 19:24, Chris Angelico wrote: On Tue, Apr 24, 2018 at 3:13 AM, Sven R. Kunze wrote: diff = x - x_base if diff and gcd(diff, n) > 1: return gcd(diff, n) # or if (x - x_base) and gcd(x - x_base, n) > 1: return gcd(x - x_base, n) and have the

Re: [Python-Dev] PEP 572: Assignment Expressions

On 04/22/2018 10:44 PM, Tim Peters wrote: [Guido] In reality there often are other conditions being applied to the match for which `if expr as name` is inadequate. The simplest would be something like if ...: elif (m := re.match('(.*):(.*)', line)) and m.group(1) == m.group(2):

Re: [Python-Dev] PEP 573 -- Module State Access from C Extension Methods

On 04/23/18 14:04, Jeroen Demeyer wrote: Hello, I just saw this PEP. There is a bit of overlap between PEP 573 and PEP 575 since these both change the calling convention for built-in methods. In particular, PEP 575 also proposes to add a "defining class" member (for different reasons). In

Re: [Python-Dev] PEP 572: Assignment Expressions

On Mon, 23 Apr 2018 16:59:35 +0100 Steve Holden wrote: > On Mon, Apr 23, 2018 at 8:28 AM, Antoine Pitrou wrote: > > > On Mon, 23 Apr 2018 00:44:44 -0500 > > Tim Peters wrote: > > ​[...] > > > > > if (diff := x - x_base) and (g

Re: [Python-Dev] PEP 573 -- Module State Access from C Extension Methods

Hello, I just saw this PEP. There is a bit of overlap between PEP 573 and PEP 575 since these both change the calling convention for built-in methods. In particular, PEP 575 also proposes to add a "defining class" member (for different reasons). In PEP 575, this is added to the PyCFunction

Re: [Python-Dev] PEP 572: Assignment Expressions

[Sven R. Kunze ] > What about > > diff = x - x_base > if diff and gcd(diff, n) > 1: > return gcd(diff, n) > > # or > > if (x - x_base) and gcd(x - x_base, n) > 1: > return gcd(x - x_base, n) > > > and have the interpreter handle the optimization, or apply an lru_cache? ;-)

Re: [Python-Dev] PEP 572: Assignment Expressions

On Tue, Apr 24, 2018 at 3:13 AM, Sven R. Kunze wrote: > On 23.04.2018 17:59, Steve Holden wrote: > > > While Tim's expression might look (superficially) like C, the five-line > alternative isn't exactly an inspiring example of Pythonicity, is it? > > > What about > > diff = x -

Re: [Python-Dev] PEP 572: Assignment Expressions

On 23.04.2018 17:59, Steve Holden wrote: While Tim's expression might look (superficially) like C, the five-line alternative isn't exactly an inspiring example of Pythonicity, is it? What about diff = x - x_base if diff and gcd(diff, n) > 1: return gcd(diff, n) # or if (x - x_base)

Re: [Python-Dev] PEP 572: Assignment Expressions

On Mon, Apr 23, 2018 at 8:28 AM, Antoine Pitrou wrote: > On Mon, 23 Apr 2018 00:44:44 -0500 > Tim Peters wrote: > ​[...] > > > if (diff := x - x_base) and (g := gcd(diff, n)) > 1: > > return g > > That's so Pythonic I could cry ;-) > > ​[...] > >

Re: [Python-Dev] PEP 572: Assignment Expressions

[Tim] >> Which this alternative expresses directly: >> >> if (diff := x - x_base) and (g := gcd(diff, n)) > 1: >> return g >> >> That's so Pythonic I could cry ;-) [Antoine] > It looks like C to me. That won't make me cry (I write C++ code daily > these days), but it's certainly not the same

[Python-Dev] PEP 573 -- Module State Access from C Extension Methods

Hello, I am an intern at Red Hat mentored by Petr Viktorin. As a part of my internship, I learned the CPython internals and how to contribute to the CPython interpreter. As a result, I have prepared PEP 573, which solves some problems that PEP 489 (Multi-phase extension module initialization) has

Re: [Python-Dev] PEP 572: Assignment Expressions

On Mon, 23 Apr 2018 00:44:44 -0500 Tim Peters wrote: > > Which this alternative expresses directly: > > if (diff := x - x_base) and (g := gcd(diff, n)) > 1: > return g > > That's so Pythonic I could cry ;-) It looks like C to me. That won't make me cry (I write C++