Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

On 10 July 2018 at 11:00, Guido van Rossum wrote: > A lot has been said about PEP 572. I am planning to accept it soon, > hopefully within a week. I realize I should have posted the draft from May > 22 (when Tim and I were added as authors and it was significantly updated -- > see

Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

On Tue, Jul 10, 2018 at 2:00 AM Terry Reedy wrote: > On 7/9/2018 9:00 PM, Guido van Rossum wrote: > > We strongly prefer feedback in the form of Pull Requests to the peps > > repo (the file is at > > https://github.com/python/peps/blob/master/pep-0572.rst > >

Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

On 7/9/2018 9:00 PM, Guido van Rossum wrote: We strongly prefer feedback in the form of Pull Requests to the peps repo (the file is at https://github.com/python/peps/blob/master/pep-0572.rst ). I couple of people have said they don't

Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

On Mon, Jul 9, 2018 at 8:24 PM, Rob Cliffe via Python-Dev < python-dev@python.org> wrote: > I apologise for not replying in the form of a Pull Request - I don't know > how to make one. > > > On 10/07/2018 02:00, Guido van Rossum wrote: > >> Rationale >> = >> >> Naming the result of an

Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

On 7/9/2018 8:43 PM, Guido van Rossum wrote: An exception to this special case applies when the target name is the same as a loop control variable for a comprehension containing it. This is invalid.  This exception exists to rule out edge cases of the above scope rules as

Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

On Mon, Jul 9, 2018 at 7:40 PM, Glenn Linderman wrote: > On 7/9/2018 6:00 PM, Guido van Rossum wrote: > > This rule is included to simplify the choice for the user between an > assignment statements and an assignment expression -- there is no > > > "statements" should not be plural in the

Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

I apologise for not replying in the form of a Pull Request - I don't know how to make one. On 10/07/2018 02:00, Guido van Rossum wrote: Rationale = Naming the result of an expression is an important part of programming, allowing a descriptive name to be used in place of a longer

Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

On 7/9/2018 6:00 PM, Guido van Rossum wrote: This rule is included to simplify the choice for the user between an   assignment statements and an assignment expression -- there is no "statements" should not be plural in the above line. syntactic position where both are valid. An exception

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

On Tue, May 1, 2018 at 2:14 AM, Steve Holden wrote: > On Tue, May 1, 2018 at 3:36 AM, Chris Jerdonek > wrote: >> >> On Thu, Apr 26, 2018 at 10:33 AM, Sven R. Kunze wrote: >> > On 25.04.2018 01:19, Steven D'Aprano wrote: >> >> >> >>

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

On Tue, May 1, 2018 at 3:36 AM, Chris Jerdonek wrote: > On Thu, Apr 26, 2018 at 10:33 AM, Sven R. Kunze wrote: > > On 25.04.2018 01:19, Steven D'Aprano wrote: > >> > >> Sorry, gcd(diff, n) is not the "perfect name", and I will tell you that > >>

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

On Tue, May 01, 2018 at 11:04:55AM +1000, Chris Angelico wrote: > To be fair, I don't see many people replacing "x = 1" with "for x in > [1]: pass". Even though it IS going to have the same effect. :-) Aside from the pass, that is precisely one of the current work-arounds for lack of

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

Steven D'Aprano wrote: "Not sure"? Given that you listed seven ways, how much more evidence do you need to conclude that it is simply wrong to say that Python has a single way to assign a value to a name? Yes, but six of those are very specialised, and there's rarely any doubt about when it's

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

On Thu, Apr 26, 2018 at 10:33 AM, Sven R. Kunze wrote: > On 25.04.2018 01:19, Steven D'Aprano wrote: >> >> Sorry, gcd(diff, n) is not the "perfect name", and I will tell you that >> sometimes g is better. [...] > > We were talking about the real-world code snippet of Tim (as a

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

On Mon, Apr 30, 2018 at 05:27:08PM -0700, Larry Hastings wrote: > > On 04/30/2018 07:30 AM, Mark Shannon wrote: > >Would Python be better with two subtly different assignment operators? > >The answer of "no" seems self evident to me. > > Maybe this has been covered in the thread earlier--if so,

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

On 04/30/2018 07:30 AM, Mark Shannon wrote: Would Python be better with two subtly different assignment operators? The answer of "no" seems self evident to me. Maybe this has been covered in the thread earlier--if so, I missed it, sorry.  But ISTM that Python already has multiple ways to

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

On Mon, Apr 30, 2018 at 1:03 PM Chris Angelico wrote: > > That's a weird argument, Chris :-) > > > > If `f(x)` has no meaningful name, then *what* is the result of the > > comprehension? Perhaps some meaningless data? ;) > f(x) might have side effects. Can you give a

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

On Tue, May 1, 2018 at 2:53 AM, Yury Selivanov wrote: > On Mon, Apr 30, 2018 at 11:32 AM Chris Angelico wrote: > >> On Tue, May 1, 2018 at 12:30 AM, Mark Shannon wrote: >> > List comprehensions >> > --- >> > The PEP uses

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

On Mon, Apr 30, 2018 at 11:32 AM Chris Angelico wrote: > On Tue, May 1, 2018 at 12:30 AM, Mark Shannon wrote: > > List comprehensions > > --- > > The PEP uses the term "simplifying" when it really means "shortening". > > One example is > > stuff

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

Le 30/04/2018 à 17:30, Chris Angelico a écrit : def do_things(fire_missiles=False, plant_flowers=False): ... do_things(plant_flowers:=True) # whoops! If you want your API to be keyword-only, make it keyword-only. If you want a linter that recognizes unused variables, get a linter that

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

On Tue, May 1, 2018 at 12:30 AM, Mark Shannon wrote: > List comprehensions > --- > The PEP uses the term "simplifying" when it really means "shortening". > One example is > stuff = [[y := f(x), x/y] for x in range(5)] > as a simplification of > stuff = [(lambda y:

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

Hi, On 17/04/18 08:46, Chris Angelico wrote: Having survived four rounds in the boxing ring at python-ideas, PEP 572 is now ready to enter the arena of python-dev. I'm very strongly opposed to this PEP. Would Python be better with two subtly different assignment operators? The answer of

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

On Fri, Apr 27, 2018 at 3:33 AM, Sven R. Kunze wrote: > On 25.04.2018 01:19, Steven D'Aprano wrote: >> >> Sorry, gcd(diff, n) is not the "perfect name", and I will tell you that >> sometimes g is better. [...] > > > We were talking about the real-world code snippet of Tim (as a

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

On 25.04.2018 01:19, Steven D'Aprano wrote: Sorry, gcd(diff, n) is not the "perfect name", and I will tell you that sometimes g is better. [...] We were talking about the real-world code snippet of Tim (as a justification of := ) and alternative rewritings of it without resorting to new

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

On Apr 24, 2018, at 2:10 PM, MRAB wrote: > > On 2018-04-21 03:15, Tim Peters wrote: >> [Tim] >> >> And I'll take this opportunity to repeat the key point for me: I >> >> tried hard, but never found a single case based on staring at real >> >> code where allowing

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

On Wed, Apr 25, 2018 at 6:15 AM, Nick Coghlan wrote: > On 25 April 2018 at 13:56, Guido van Rossum wrote: > > On Tue, Apr 24, 2018 at 8:24 PM, Nick Coghlan > wrote: > >> > >> I also think it would be good for the PEP to spell out the

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

On 25 April 2018 at 13:56, Guido van Rossum wrote: > On Tue, Apr 24, 2018 at 8:24 PM, Nick Coghlan wrote: >> >> I also think it would be good for the PEP to spell out the following >> semantic invariant for code running in a regular namespace: >> >> _rhs

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

On Tue, Apr 24, 2018 at 8:24 PM, Nick Coghlan wrote: > I also think it would be good for the PEP to spell out the following > semantic invariant for code running in a regular namespace: > > _rhs = expr > assert (target := _rhs) is _rhs and target is _rhs > > It's the

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

On 25 April 2018 at 06:23, Mike Miller wrote: > Now, I agree that's not a difference of much consequence, but the difference > from "import as" is not either. Since this example has been brought up by a few folks now, I'll note that "import x.y.z as c" has never been

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

On 25 April 2018 at 03:01, Tim Peters wrote: > assignment statement buried deep inside expressions. But in > conventional use, "binding" is restricted to identifiers, which vastly > simplifies the mental model for "the worst" that can happen. [snip] > But, in the absence

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

On Tue, Apr 24, 2018 at 10:42:35PM +0200, Sven R. Kunze wrote: > gcd(diff, n) is to me a perfect name, and please don't tell me g is > better. ;) Sorry, gcd(diff, n) is not the "perfect name", and I will tell you that sometimes g is better. Which would you prefer to see and read? g =

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

On 23.04.2018 23:41, Tim Peters wrote: Why? "Give the result of an expression a name" is already heavily used in Python - it's just that the _contexts_ in which it can be done are very limited now. Which is a good thing IMO. It keeps stuff simple to reason about. At least to me, the objective

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

On 2018-04-24 12:59, Chris Angelico wrote: Aside from the restriction to binding only to a simple name, and the fact that they're also an expression with the same value, how are they not the same as plain assignment? Any discrepancies should be considered bugs. Slightly different in that they

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

On 2018-04-23 14:19, Barry Warsaw wrote: Me too. Plus we *already* have precedence for spelling name bindings in similar constructs, such as import statements, with statements, and exceptions. It seems like a natural and Pythonic approach to extend that same spelling to binding expressions

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

On 04/24/2018 12:59 PM, Chris Angelico wrote: On Wed, Apr 25, 2018 at 5:54 AM, Mike Miller wrote: Also, these "binding expressions" are not exactly plain assignment, as it has been known. Aside from the restriction to binding only to a simple name, and the fact that they're also an

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

On Wed, Apr 25, 2018 at 5:54 AM, Mike Miller wrote: > Also, these "binding expressions" are not exactly plain assignment, as it > has been known. Aside from the restriction to binding only to a simple name, and the fact that they're also an expression with the same

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

On 2018-04-23 15:36, Guido van Rossum wrote: - the semantics are subtly different from all other uses of 'as' in Python; I'd like to reserve 'as' for "not a plain assignment" It's conceptually similar to "import as", no? The keyword "as" is a fuzzy yet intuitive concept already. Also,

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

> > Just reading this: > > https://www.bfilipek.com/2018/04/refactoring-with-c17-stdoptional.html > > about C++17, and what did I see? An example with a semicolon in > parentheses! > Isn't that kind of the C++ motto? "Leave no syntactic stone unturned." Whereas in Python, the syntax motto might

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

On 2018-04-21 03:15, Tim Peters wrote: [Tim] >> And I'll take this opportunity to repeat the key point for me: I >> tried hard, but never found a single case based on staring at real >> code where allowing _fancier_ (than "plain name") targets would be a >> real improvement. In every case I

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

[Chris Angelico ] > Hopefully you have seen, or soon will see, the latest posting of the > PEP, in which assignment targets are restricted to simple names. :) I haven't yet, but look forward to it! You have the patience of a saint to endure all this - I would have given up 6

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

On Wed, Apr 25, 2018 at 2:40 AM, Tim Peters wrote: > [Antoine] >> ... >> Yes... I think most will agree that Python is generally easy to take up >> for people coming from C++ etc., so my "easier to learn and teach" was >> mostly about non-programmers. > > [Tim] >>> even for

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

[Antoine] > ... > Yes... I think most will agree that Python is generally easy to take up > for people coming from C++ etc., so my "easier to learn and teach" was > mostly about non-programmers. [Tim] >> even for raw beginners the semantics are the tiniest part of what >> they need to learn

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

On 04/23/2018 06:42 PM, Chris Jerdonek wrote: 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

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

On 24 April 2018 at 22:30, David Mertz wrote: > I do think the pronunciation issue that Greg notices is important. I teach > Python for most of my living, and reading and discussing code segments is an > important part of that. When focussing on how Python actually *spells* >

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

I do think the pronunciation issue that Greg notices is important. I teach Python for most of my living, and reading and discussing code segments is an important part of that. When focussing on how Python actually *spells* something, you can't always jump to the higher-level meaning of a

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

What facilities does the interpreter currently have for extracting common subexpressions, and how would it verify in such a dynamic environment that such extractions wouldn't alter the semantics of the program? Explicit (assignment using :=) is better than implicit (by optimizations hidden to the

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

On Tue, 24 Apr 2018 01:55:13 -0500 Tim Peters wrote: > [Antoine] > > Constructs like "with ..." or "try / except / finally" make the > > language easier to learn compared to the dances they are meant to > > replace. > > They nevertheless need to be taught & learned (and

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

On 24/04/2018 02:42, Chris Jerdonek wrote: 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

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

[Stephen J. Turnbull[ >> Neologisms are usually written in the other order: >> "dead on arrival (DOA, for short)." ;-) [Greg Ewing ] > Maybe we can make use of that? > >if (x - x_base) (diff) and gcd(diff, n) (g) > 1: > > That doesn't work, because the (...) look

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

On 24 April 2018 at 08:12, Greg Ewing wrote: > Chris Jerdonek wrote: > > if (diff := x - x_base) and (g := gcd(diff, n)) > 1: >>> > "if diff, which we let equal x - x_base, and g, which ..." or >> "if diff, which we set equal to x - x_base, and g, which " or

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

On Tue, Apr 24, 2018 at 5:23 PM, Greg Ewing wrote: > Stephen J. Turnbull wrote: >> >> Neologisms are usually written in the >> other order: "dead on arrival (DOA, for short)." ;-) > > > Maybe we can make use of that? > >if (x - x_base) (diff) and gcd(diff, n) (g)

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

[Antoine Pitrou ] > ... > Having to break things out over multiple lines is a fact of life, if > only for readability when implementing (and maintaining!) non-trivial > processing routines. It's a good thing to be used to it, and to learn to > choose good names for

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

On Tue, Apr 24, 2018 at 5:12 PM, Greg Ewing wrote: > Chris Jerdonek wrote: > if (diff := x - x_base) and (g := gcd(diff, n)) > 1: > > >> "if diff, which we let equal x - x_base, and g, which ..." or >> "if diff, which we set equal to x - x_base, and g, which

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

Stephen J. Turnbull wrote: Neologisms are usually written in the other order: "dead on arrival (DOA, for short)." ;-) Maybe we can make use of that? if (x - x_base) (diff) and gcd(diff, n) (g) > 1: That doesn't work, because the (...) look like function calls. But what if we used a

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

Chris Jerdonek wrote: if (diff := x - x_base) and (g := gcd(diff, n)) > 1: "if diff, which we let equal x - x_base, and g, which ..." or "if diff, which we set equal to x - x_base, and g, which " or "if diff, which we define to be x - x_base, and g, which " or "if diff, which we

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

On Tue, 24 Apr 2018 16:38:39 +1000 Chris Angelico wrote: > On Tue, Apr 24, 2018 at 4:27 PM, Antoine Pitrou wrote: > > On Tue, 24 Apr 2018 01:06:30 -0500 > > Tim Peters wrote: > >> > >> > - does it make Python easier to learn and

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

[Antoine] >>> - does it make Python easier to learn and teach? [Tim] >> By whom? Almost no addition has ever made a language easier to learn >> for raw beginners: every addition is something they eventually need >> to learn. We could make Python easier to learn for beginners by >> throwing out

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

On Tue, Apr 24, 2018 at 4:27 PM, Antoine Pitrou wrote: > On Tue, 24 Apr 2018 01:06:30 -0500 > Tim Peters wrote: >> >> > - does it make Python easier to learn and teach? >> >> By whom? Almost no addition has ever made a language easier to learn >> for

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

On Tue, 24 Apr 2018 01:06:30 -0500 Tim Peters wrote: > > > - does it make Python easier to learn and teach? > > By whom? Almost no addition has ever made a language easier to learn > for raw beginners: every addition is something they eventually need > to learn. We

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

[Steve Holden ] >> ... >> The assignment expression seems like a vary natural way to introduce >> variables of limited (controlled?) scope, [...] [Antoine Pitrou ] > AFAIU, the scope isn't limited to the "if" block, it's a regular local > variable. I

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

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

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

[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): > > > And the match() call may

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

Please stop debating ` as `. Nobody is being swayed by anything in this subthread. Let's move on. On Sun, Apr 22, 2018 at 3:27 PM, Chris Angelico wrote: > On Mon, Apr 23, 2018 at 8:20 AM, Mike Miller > wrote: > > > > On 2018-04-22 14:33, Chris

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

On Sun, Apr 22, 2018 at 3:13 PM, Steve Dower wrote: > This example makes me want “if expr as name:” (same semantics as ‘with’, > and the name is always bound to the expression result regardless of > truthiness), but doesn’t move me on assignment expressions. > In reality

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

On Mon, Apr 23, 2018 at 8:20 AM, Mike Miller wrote: > > On 2018-04-22 14:33, Chris Angelico wrote: >> >> with open(fn) as f: >> with (open(fn) as f): >> >> These two do the same thing, but only because a file object's >> __enter__ returns self. So it's dangerous, because

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

On 2018-04-22 14:33, Chris Angelico wrote: with open(fn) as f: with (open(fn) as f): These two do the same thing, but only because a file object's __enter__ returns self. So it's dangerous, because it WILL work... and people will get into the habit of parenthesizing to permit a 'with'

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

21, 2018 19:09 To: Steven D'Aprano Cc: Python-Dev Subject: Re: [Python-Dev] PEP 572: Assignment Expressions On Sat, Apr 21, 2018 at 6:13 PM, Steven D'Aprano <st...@pearwood.info> wrote: On Sat, Apr 21, 2018 at 08:35:51PM +0100, Matthew Woodcraft wrote: > Well, that's a reason to make th

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

On Mon, Apr 23, 2018 at 6:22 AM, Mike Miller wrote: > On 2018-04-22 12:37, Chris Angelico wrote: >> Kinda, except that that's not quite a match either. But mainly, the >> comparison with 'with' and 'except' is dangerously incompatible. > > Hmm, looks very close

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

On 2018-04-22 12:37, Chris Angelico wrote: > Kinda, except that that's not quite a match either. But mainly, the > comparison with 'with' and 'except' is dangerously incompatible. Hmm, looks very close conceptually, though mechanics are different. Dangerous feels like an exaggeration however.

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

On 2018-04-21 19:57, Chris Angelico wrote: Thanks for being patient. Looks like the crux of the issue is that "with … as" binds the result of the enter function rather than the context-manager object, as it might first appear. Therefore it's not compatible with how "as" is used for direct

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

2018-04-22 14:10 GMT+03:00 Kirill Balunov : > > Although one of the prerequisites for writing this PEP was the use of the > assignment expression in the lists > Sorry, typo: in compehensions/generators. > it will rarely be used in them, and even more rarely it will be

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

2018-04-21 4:44 GMT+03:00 Tim Peters : > [Chris Angelico ] > > I don't see much value in restricting the assignment target to names > > only, but if that's what it takes, it can be restricted, at least > > initially. > > I believe this point was made most

  1   2   3   >