Re: [Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

>> We're focused on Python 3.8 and 3.9, not Python 5 or Python 6. Hmmm... When I was hearing the repeated belated saying that Python will never ever jump on the statically typed ship on each and every static type annotation discussion I started to worry this wasn't indeed the case (why the urge of

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

On 04/26/2018 09:02 PM, Alex Walters wrote: http://pyvideo.org/pycascades-2018/bdfl-python-3-retrospective.html link to Guido’s talk, for your convenience Many thanks! -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python

Re: [Python-Dev] PEP 394 update proposal: Allow changing the `python` command in some cases

Ben Finney writes: > Petr Viktorin writes: > > > […] we feel that the only way to *enforce* that guidelines is to > > provide environments where the `python` command does not work > > (unless explicitly installed). > > Yes. The ‘python’ command is confusing, for the reasons you say. There > shou

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, Apr 26, 2018 at 08:48:12AM -0700, Łukasz Langa wrote: > > > On Apr 25, 2018, at 11:10 PM, Steven D'Aprano wrote: > > Criticising binding- > > expressions for that reason, especially implying that we must always use > > parens, is simply FUD. > > The PEP has more examples with parenthes

Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

Sorry all, wasn't specific enough. By "modern" I mean the last decade perhaps. New languages that have had a chance to look at the older generations and choose their best ideas, while leaving behind the rest. Personally I thought of Swift (Ryan mentioned), Kotlin, Rust, and perhaps Go, thou

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

http://pyvideo.org/pycascades-2018/bdfl-python-3-retrospective.html link to Guido’s talk, for your convenience From: Python-Dev On Behalf Of Guido van Rossum Sent: Thursday, April 26, 2018 6:12 PM To: Brett Cannon Cc: Barry Warsaw ; Python-Dev Subject: Re: [Python-Dev] (Looking for) A Retr

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Zero Piraeus] >> Since it now looks like it really *does* have a decent chance, and >> maybe another -1 has a small chance of tipping the balance: my >> reaction to the proposal is also emotional. Visceral, in fact, to the >> extent that I'd aim to read and write less Python if it became >> common

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

[Larry Hastings ] >>> I hate to be pedantic--there's enough of that going on in this thread--but I >>> can't agree with the word "simplifed" above. I agree that the code using >>> binding expressions is shorter. But considering that emit the two code >>> examples implement the exact same algorith

Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

On Fri, Apr 27, 2018 at 10:52 AM Paul G wrote: > Rust has a few syntactic ways to accomplish the same thing, though. I think match expressions are used for the equivalent of conditionals that carry the condition value into the body of the expression, and all blocks return the result of the last s

Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

Rust has a few syntactic ways to accomplish the same thing, though. I think match expressions are used for the equivalent of conditionals that carry the condition value into the body of the expression, and all blocks return the result of the last statement, so you can do things like: let mut x;

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

On Thu, Apr 26, 2018 at 4:27 PM, Kirill Balunov wrote: > > > 2018-04-24 18:31 GMT+03:00 Chris Angelico : >> >> >> > > Not sure, but if additional motivating examples are required, there is a > common pattern for dynamic attribute lookup (snippet from `copy.py`): > > reductor = dispatch_table.g

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, Apr 26, 2018 at 08:00:46PM +0100, Zero Piraeus wrote: > Since it now looks like it really *does* have a decent chance, and > maybe another -1 has a small chance of tipping the balance: my > reaction to the proposal is also emotional. Visceral, in fact, to the > extent that I'd aim to read

Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

On Thu, Apr 26, 2018 at 09:36:48AM -0700, Mike Miller wrote: > However, there were two good questions in this message which I haven't seen > addressed yet: > > - How are other modern languages solving this issue? > - How does this new construct intersect with typing functionality? What

Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

[Mike Miller] >> - How are other modern languages solving this issue? [Greg Ewing ] > In all the languages I can think of that allow assignments in > expressions, there is only one assignment operator -- a stand > alone assignment is just a bare assignment expression. Pretty much so, but I do

Re: [Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

Hi Fatty, and welcome! On Thu, Apr 26, 2018 at 08:00:55PM +0200, Fatty Morgan wrote: > The natural interpretation of 'name := expr' is a PEP 526 > type-annotated variable initialization 'name : T = expr' with the > type annotation T omitted, the tokens ':' and '=' coalesced, and > the implied typ

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

On 04/26/2018 12:12 PM, Tim Peters wrote: [Larry Hastings ] I hate to be pedantic--there's enough of that going on in this thread--but I can't agree with the word "simplifed" above. I agree that the code using binding expressions is shorter. But considering that emit the two code examples im

Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

Mike Miller wrote: - How are other modern languages solving this issue? In all the languages I can think of that allow assignments in expressions, there is only one assignment operator -- a stand alone assignment is just a bare assignment expression. But those languages were all designed t

Re: [Python-Dev] PEP 394 update proposal: Allow changing the `python` command in some cases

Petr Viktorin writes: > In Fedora, I found that PEP 394's strict recommendation that `python` > points to `python2` is holding us back. I have read the message, but I don't see how you draw the link that PEP 394 is holding you back. > The problems are: > - For developers that are not following

Re: [Python-Dev] PEP 572: Why not := as standard assignment operator?

Chris Angelico wrote: No. Any expression may be used as a statement, so this isn't "outside an expression". It could be detected as a special case and rejected some time later in the compilation process. The question is whether it's worth making the rules more complicated just to forbid somethi

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

Also see my talk at PyCascades and Victor's upcoming talk at PyCon. On Thu, Apr 26, 2018, 12:02 Brett Cannon wrote: > > > On Thu, 26 Apr 2018 at 10:19 Barry Warsaw wrote: > >> On Apr 26, 2018, at 09:28, Eric Snow wrote: >> > >> > On Thu, Apr 26, 2018 at 10:25 AM, Eric Snow < >> ericsnowcurren.

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

2018-04-26 13:20 GMT+03:00 Steve Holden : > On Thu, Apr 26, 2018 at 8:56 AM, Steven D'Aprano > wrote: > >> On Thu, Apr 26, 2018 at 03:31:13AM -0400, Terry Reedy wrote: >> > On 4/25/2018 8:20 PM, Chris Angelico wrote: >> > >On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov >> > > wrote: >> > >>Just

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Tim] >> So, to match your sarcasm, here's mine: try using a feature for what >> it's good at instead of for what it's bad at ;-) [Lukasz Langa ] > Yes, this is the fundamental wisdom. Judging which is which is left as an > exercise to the programmer. > > With this, I'm leaving the discussion.

[Python-Dev] Nickname Binding (PEP 572)

I think part of the disconnect is that this enhancement could very easily be abused, and it seems likely that it will be, because the problems aren't visible while writing the code -- only when reading it later. I therefore suggest making it very clear in the PEP -- and probably in PEP 8 -- how t

Re: [Python-Dev] PEP 572: Why not := as standard assignment operator?

On 4/26/2018 11:38 AM, Gustavo Carneiro wrote: On Thu, Apr 26, 2018 at 11:13 PM, Martin Teichmann mailto:lkb.teichm...@gmail.com>> wrote: > when reading PEP 572 I actually liked it a lot - I think it's actually > a cool idea. I think it's actually that cool an idea that it should

Re: [Python-Dev] Boundaries between numbers and identifiers

26.04.18 22:02, Lukasz Langa пише: On Apr 26, 2018, at 11:37 AM, Serhiy Storchaka wrote: I propose to change the Python syntax by adding a requirement that there should be a whitespace or delimiter between a numeric literal and the following keyword. -1 This would make Python 3.8 reject cod

Re: [Python-Dev] Order of positional and keyword arguments

I see no practical benefit to making such a restriction, and there's a risk of breaking existing code. While it's not something I've ever used myself in real code, def wrapper(*args, **kw): return wrapped_fn(some_arg=1, *args, **kw) seems like a perfectly reasonable way to write a wr

[Python-Dev] Order of positional and keyword arguments

There is an inconsistence in passing arguments to functions. Explicit positional arguments should precede keyword arguments (both explicit and variable), but variable positional arguments can follow explicit keyword arguments and precede variable keyword arguments. For example, for function

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

[Kirill Balunov] > Not sure, but if additional motivating examples are required, there is a > common pattern for dynamic attribute lookup (snippet from `copy.py`): > > reductor = dispatch_table.get(cls) > if reductor: > rv = reductor(x) > else: > reductor = getattr(x, "_

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On 4/26/2018 6:34 AM, Greg Ewing wrote: Antoine Pitrou wrote: Well, how do languages where assignment is an expression returning the assigned value make their REPLs work?  I'm sure they don't inflict that on their users, so it's certainly a solvable problem. I can't think of any such language

Re: [Python-Dev] Boundaries between numbers and identifiers

> On Apr 26, 2018, at 11:37 AM, Serhiy Storchaka wrote: > > I propose to change the Python syntax by adding a requirement that there > should be a whitespace or delimiter between a numeric literal and the > following keyword. -1 This would make Python 3.8 reject code due to stylistic prefere

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

: On 25 April 2018 at 21:28, Guido van Rossum wrote: > A very emotional appeal, you don't seem to grasp the usability improvements > this will give. I hear you but at this point appeals to Python's "Zen" don't > help you. I have to admit, in half-following this discussion I've swung between thin

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

On Thu, 26 Apr 2018 at 10:19 Barry Warsaw wrote: > On Apr 26, 2018, at 09:28, Eric Snow wrote: > > > > On Thu, Apr 26, 2018 at 10:25 AM, Eric Snow > wrote: > >> In pondering our approach to future Python major releases, I found > >> myself considering the experience we've had with Python 3. Th

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

On 04/26/18 09:32, Thomas Wouters wrote: Thanks for working on this, Marcel (and Petr). This looks like an ambitious intern project :) Couple of questions and comments in-line. Indeed, but also a multi-year one. Sometimes it seems like Python is moving too fast under us! Specifically, PEP

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On 4/26/2018 6:20 AM, Steve Holden wrote: On Thu, Apr 26, 2018 at 8:56 AM, Steven D'Aprano > wrote: On Thu, Apr 26, 2018 at 03:31:13AM -0400, Terry Reedy wrote: > On 4/25/2018 8:20 PM, Chris Angelico wrote: > >On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivan

[Python-Dev] Boundaries between numbers and identifiers

In Python 2.5 `0or[]` was accepted by the Python parser. It became an error in 2.6 because "0o" became recognizing as an incomplete octal number. `1or[]` still is accepted. On other hand, `1if 2else 3` is accepted despites the fact that "2e" can be recognized as an incomplete floating point nu

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

On 04/26/2018 11:18 AM, Chris Angelico wrote: In the reference implementation, it's just DUP_TOP followed by STORE_FAST (well, technically by "whatever the assignment compiles to", as it could be affected by global/nonlocal, closures, etc). Is there much advantage to creating a new opcode? Pr

Re: [Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

> On Apr 26, 2018, at 11:00 AM, Fatty Morgan wrote: > > I would like to urge you to reconsider the use of the token ':=' > for assignment expressions. > > The natural interpretation of 'name := expr' is a PEP 526 > type-annotated variable initialization 'name : T = expr' with the > type annotat

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

With the new name restriction on the LHS, I'm now -0 on this. While I don't think the benefits outweigh the overhead cost of pushing Python closer to not fitting in my brain, I would admittedly use this if provided to me. (I also put this in the bucket of consenting adult features; ripe for abuse,

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

On Fri, Apr 27, 2018 at 4:07 AM, Larry Hastings wrote: > * I assume that--if we don't already have one--we'll add a new > DUP_AND_STORE_FAST opcode for binding expressions. On the other hand, > "STORE_FAST n" followed by "LOAD_FAST n" is a common enough bytecode idiom > that the peephole optimize

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Uncle T] > So, to match your sarcasm, here's mine: try using a feature for what > it's good at instead of for what it's bad at ;-) Yes, this is the fundamental wisdom. Judging which is which is left as an exercise to the programmer. With this, I'm leaving the discussion. With Guido and you on

[Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

I would like to urge you to reconsider the use of the token ':=' for assignment expressions. The natural interpretation of 'name := expr' is a PEP 526 type-annotated variable initialization 'name : T = expr' with the type annotation T omitted, the tokens ':' and '=' coalesced, and the implied type

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

On 04/26/2018 06:27 AM, Kirill Balunov wrote: Not sure, but if additional motivating examples are required, there is a common pattern for dynamic attribute lookup (snippet from `copy.py`):     reductor = dispatch_table.get(cls)     if reductor:     rv = reductor(x)     else:     reduc

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

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

On 24.04.2018 11:21, Victor Stinner wrote: I have been asked to express myself on the PEP 572. +1 I knew about the relationship between read and write. But your stance on debugging just makes it a thing. Thanks a lot! ___ Python-Dev mailing list Py

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 synta

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

On Apr 26, 2018, at 09:28, Eric Snow wrote: > > On Thu, Apr 26, 2018 at 10:25 AM, Eric Snow > wrote: >> In pondering our approach to future Python major releases, I found >> myself considering the experience we've had with Python 3. The whole >> Py3k effort predates my involvement in the commu

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

[Kirill Balunov ] > Not sure, but if additional motivating examples are required, there is a > common pattern for dynamic attribute lookup (snippet from `copy.py`): > > reductor = dispatch_table.get(cls) > if reductor: > rv = reductor(x) > else: > reductor = getattr(x, "

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

2018-04-24 18:31 GMT+03:00 Chris Angelico : > > Recommended use-cases > = > > [...] > > # Capturing regular expression match objects > # See, for instance, Lib/pydoc.py, which uses a multiline spelling > # of this effect > if match := re.search(pat, text): >

[Python-Dev] Every Release Can Be a Mini "Python 4000", Within Reason (was (name := expression) doesn't fit the narrative of PEP 20)

On Thu, Apr 26, 2018 at 12:52 AM, Greg Ewing wrote: > [snip] > here we would be *creating* one (two different assignment > operators with overlapping use cases) that we won't be > able to get rid of without a Python 4000 (that Guido has > promised won't happen). The edict about "Python 4000" is m

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

[Guido] > Maybe the order for d[k] = v should also be reconsidered? There's certainly code in the wild relying on the order "v, then d, then k", because that's just how assignment statements have always worked (dicts or not). I'd rather change the dict comprehension code, because I think the anal

Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

On 2018-04-25 19:36, Ryan Gonzalez wrote: By now we've searched over the current proposal in excruciating detail. However, there were two good questions in this message which I haven't seen addressed yet: - How are other modern languages solving this issue? - How does this new constru

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

On Thu, Apr 26, 2018 at 10:25 AM, Eric Snow wrote: > In pondering our approach to future Python major releases, I found > myself considering the experience we've had with Python 3. The whole > Py3k effort predates my involvement in the community so I missed a > bunch of context about the motivati

[Python-Dev] (Looking for) A Retrospective on the Move to Python 3

In pondering our approach to future Python major releases, I found myself considering the experience we've had with Python 3. The whole Py3k effort predates my involvement in the community so I missed a bunch of context about the motivations, decisions, and challenges. While I've pieced some of th

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

FWIW There's an existing issue (bpo 29652 ) for the order of evaluation in dict-comps. Best Regards, Jim Fasarakis Hilliard On Thu, Apr 26, 2018 at 7:06 PM, Chris Angelico wrote: > On Fri, Apr 27, 2018 at 2:02 AM, Guido van Rossum > wrote: > > Maybe the o

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

On Fri, Apr 27, 2018 at 2:02 AM, Guido van Rossum wrote: > Maybe the order for d[k] = v should also be reconsidered? If so, it would be something like: 1) Evaluate d 2) Evaluate k 3) Evaluate v 4) Call d.__setitem__(k, v), via slots etc In a vacuum, I don't have a problem with that. But I suspe

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

Maybe the order for d[k] = v should also be reconsidered? On Thu, Apr 26, 2018, 08:23 Chris Angelico wrote: > On Fri, Apr 27, 2018 at 1:07 AM, Guido van Rossum > wrote: > > Just as I feared. While currently fixing this is just fixing a bug > (nobody's > > code is going to break except perhaps s

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

> On Apr 25, 2018, at 11:10 PM, Steven D'Aprano wrote: > Criticising binding- > expressions for that reason, especially implying that we must always use > parens, is simply FUD. The PEP has more examples with parentheses than without. >> As soon as we have to wrap a part of an expression in p

Re: [Python-Dev] PEP 572: Why not := as standard assignment operator?

On Fri, Apr 27, 2018 at 1:38 AM, Gustavo Carneiro wrote: > > > On 26 April 2018 at 16:18, Chris Angelico wrote: >> >> On Thu, Apr 26, 2018 at 11:13 PM, Martin Teichmann >> wrote: >> > Hi list, >> > >> > when reading PEP 572 I actually liked it a lot - I think it's actually >> > a cool idea. I th

Re: [Python-Dev] PEP 572: Why not := as standard assignment operator?

On 26 April 2018 at 16:18, Chris Angelico wrote: > On Thu, Apr 26, 2018 at 11:13 PM, Martin Teichmann > wrote: > > Hi list, > > > > when reading PEP 572 I actually liked it a lot - I think it's actually > > a cool idea. I think it's actually that cool an idea that it should be > > made the defau

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

On Fri, Apr 27, 2018 at 1:07 AM, Guido van Rossum wrote: > Just as I feared. While currently fixing this is just fixing a bug (nobody's > code is going to break except perhaps some tests), with PEP 572 fixing this > would be mandatory. > > On Thu, Apr 26, 2018 at 6:57 AM, Nick Coghlan wrote: >> >

Re: [Python-Dev] PEP 572: Why not := as standard assignment operator?

On Thu, Apr 26, 2018 at 11:13 PM, Martin Teichmann wrote: > Hi list, > > when reading PEP 572 I actually liked it a lot - I think it's actually > a cool idea. I think it's actually that cool an idea that it should be > made the default way of doing an assignment, over time phasing out the > good o

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

Just as I feared. While currently fixing this is just fixing a bug (nobody's code is going to break except perhaps some tests), with PEP 572 fixing this would be mandatory. On Thu, Apr 26, 2018 at 6:57 AM, Nick Coghlan wrote: > On 25 April 2018 at 18:23, Chris Angelico wrote: > x={print(2)

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

On 2018-04-26 16:37, Nick Coghlan wrote: PEP 487 refers to this as the "owner" of a descriptor That's just copied from the Python docs: https://docs.python.org/3.8/reference/datamodel.html#object.__get__ Anyway, I never liked the name "owner" there, "cls" would have been much clearer. For

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

On 26 April 2018 at 04:46, Jeroen Demeyer wrote: > On 2018-04-25 20:33, Petr Viktorin wrote: >> >> Perhaps "m_objclass" could point to the module in this case > > > That was exactly my idea also today. Instead of treating m_objclass as the > defining class, we should generalize it to be the "paren

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On 26 April 2018 at 15:38, Chris Angelico wrote: > On Thu, Apr 26, 2018 at 3:34 PM, Steven D'Aprano wrote: >> Can you give an example of a Python expression, involving PEP 572 >> binding-expressions, that is not a tree but a more general DAG or that >> contains cycles? > > A DAG is a directed *ac

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

On 25 April 2018 at 18:23, Chris Angelico wrote: x={print(2): print(1) for _ in [1]} > 1 > 2 > > Hm. One of these is not like the others... Huh, it looks like we missed checking dict comprehensions when we fixed dict displays to evaluate keys before the corresponding values. That wou

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

Thanks for working on this, Marcel (and Petr). This looks like an ambitious intern project :) Couple of questions and comments in-line. On Mon, Apr 23, 2018 at 12:36 PM, Marcel Plch wrote: > Hello, > I am an intern at Red Hat mentored by Petr Viktorin. As a part of my > internship, I learned the

[Python-Dev] PEP 572: Why not := as standard assignment operator?

Hi list, when reading PEP 572 I actually liked it a lot - I think it's actually a cool idea. I think it's actually that cool an idea that it should be made the default way of doing an assignment, over time phasing out the good ole =. This would have several benefits: - people wouldn't have to wo

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

FWIW, the combination of limiting the PEP to binding expressions and the motivating example of sequential if/elif tests that each need to utilize an expression in their body (e.g. matching various regexen by narrowing, avoiding repeated indent) gets me to +1. I still think the edge case changes to

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

On Thu, Apr 26, 2018 at 9:23 PM, Stephen J. Turnbull wrote: > Chris Angelico writes: > > > Well, true. The point isn't WHO you're dictating to, > > By "period here preferred," I meant I think it's mostly a waste of > space to mention dictation at all in that document. But it's not a > big deal t

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, Apr 26, 2018 at 10:34:29PM +1200, Greg Ewing wrote: > Antoine Pitrou wrote: > >Well, how do languages where assignment is an expression returning the > >assigned value make their REPLs work? I'm sure they don't inflict that > >on their users, so it's certainly a solvable problem. > > I ca

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, Apr 26, 2018 at 10:17:34AM +0200, Antoine Pitrou wrote: > I also wonder how long it will be before someone writes: > > def f(arg): > global _lazy_value > if predicate(arg) and (_lazy_value := frobnicate()) > arg: > ... > > (or something similar with "nonlo

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

> > [Raymond Hettinger ] > > Python is special, in part, because it is not one of those languages. > > It has virtues that make it suitable even for elementary school children. > > We can show well-written Python code to non-computer folks and walk > > them through what it does without their brains

Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

On Thu, 26 Apr 2018 20:35:20 +0900 "Stephen J. Turnbull" wrote: > Steven D'Aprano writes: > > On Wed, Apr 25, 2018 at 09:36:31PM -0500, Ryan Gonzalez wrote: > > > > Now, what's the common theme here? **Declarations should be separate > from > > > expressions.** > > > > Declarations a

Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

Steven D'Aprano writes: > On Wed, Apr 25, 2018 at 09:36:31PM -0500, Ryan Gonzalez wrote: > > Now, what's the common theme here? **Declarations should be separate from > > expressions.** > > Declarations and assignments are not the same thing. Ryan mostly meant "initialization" rather than

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

Łukasz Langa writes: > > On 25 Apr, 2018, at 5:20 PM, Chris Angelico wrote: > You're claiming that `:=` is nicer in this situation because it's less > prominent than regular assignment and thus doesn't suggest that the name > stays visible later. FWIW, I read what he wrote as "*assuming* buf

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

Chris Angelico writes: > Well, true. The point isn't WHO you're dictating to, By "period here preferred," I meant I think it's mostly a waste of space to mention dictation at all in that document. But it's not a big deal to me, so how about changing "a student or junior programmer" to "another

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

Antoine Pitrou wrote: Depends if you mean a graph between names or values? > If between names, you can even have cycles AFAICT: ((a: = a + b), (b: = a)) I was thinking more of the dataflow graph. That's not a cycle between *values*, since the new values being bound are calculated from the

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

Antoine Pitrou wrote: Well, how do languages where assignment is an expression returning the assigned value make their REPLs work? I'm sure they don't inflict that on their users, so it's certainly a solvable problem. I can't think of any such language that has a REPL offhand, but here's a pos

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, Apr 26, 2018 at 8:56 AM, Steven D'Aprano wrote: > On Thu, Apr 26, 2018 at 03:31:13AM -0400, Terry Reedy wrote: > > On 4/25/2018 8:20 PM, Chris Angelico wrote: > > >On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov > > > wrote: > > >>Just yesterday this snippet was used on python-dev to sho

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Wed, Apr 25, 2018 at 9:55 PM, Łukasz Langa wrote: > > > On 25 Apr, 2018, at 1:28 PM, Guido van Rossum wrote: > > > > You don't seem to grasp the usability improvements this will give. I > hear you but at this point appeals to Python's "Zen" don't help you. > > This reads dismissive to me. I d

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, 26 Apr 2018 19:19:05 +1000 Chris Angelico wrote: > > > > If such were the need, you could very well make it part of the language > > specification. We are talking about a trivial optimization that any > > runtime could easily implement (e.g. if a sequence `DUP_TOP, STORE_FAST, > > POP_TOP

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, Apr 26, 2018 at 6:30 PM, Antoine Pitrou wrote: > On Thu, 26 Apr 2018 17:29:17 +1000 > Steven D'Aprano wrote: >> On Thu, Apr 26, 2018 at 07:16:28PM +1200, Greg Ewing wrote: >> > Tim Peters wrote: >> > >As a statement in a program (as opposed to typed at a shell), >> > >"a := 3" has the unn

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

- In Python code, __objclass__ should be the defining class, not the module. Indeed. My idea would be to add an accessor __parent__ returning the m_parent field (whatever it is) and then implement __objclass__ as something like: @property def __objclass__(self): parent = getattr(self, "_

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, 26 Apr 2018 15:34:17 +1000 Steven D'Aprano wrote: > On Thu, Apr 26, 2018 at 05:22:58PM +1200, Greg Ewing wrote: > > Łukasz Langa wrote: > > >What was its own assignment before > > >now is part of the logic test. This saves on vertical whitespace but makes > > >parsing and understanding

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, 26 Apr 2018 17:29:17 +1000 Steven D'Aprano wrote: > On Thu, Apr 26, 2018 at 07:16:28PM +1200, Greg Ewing wrote: > > Tim Peters wrote: > > >As a statement in a program (as opposed to typed at a shell), > > >"a := 3" has the unnecessary (in that context) property of returning > > >(and dis

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

On Wed, Apr 25, 2018 at 11:53 PM, Chris Angelico wrote: > Well, true. The point isn't WHO you're dictating to, but that you can > dictate it at all. "Hmm, let's see. Toss a 'foo colon-equals' in front > of X, then print out what foo is." My day job involves a lot of > helping students learn how to

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Wed, 25 Apr 2018 18:52:34 -0700 Łukasz Langa wrote: > > On 25 Apr, 2018, at 5:20 PM, Chris Angelico wrote: > > > > On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov > > wrote: > >> Just yesterday this snippet was used on python-dev to show how great the > >> new syntax is: > >> > >>

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, Apr 26, 2018 at 03:31:13AM -0400, Terry Reedy wrote: > On 4/25/2018 8:20 PM, Chris Angelico wrote: > >On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov > > wrote: > >>Just yesterday this snippet was used on python-dev to show how great the > >>new syntax is: > >> > >> my_func(arg,

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On 4/25/2018 8:20 PM, Chris Angelico wrote: On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov wrote: Just yesterday this snippet was used on python-dev to show how great the new syntax is: my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf)) What strikes me as awful about

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, Apr 26, 2018 at 07:16:28PM +1200, Greg Ewing wrote: > Tim Peters wrote: > >As a statement in a program (as opposed to typed at a shell), > >"a := 3" has the unnecessary (in that context) property of returning > >(and discarding 3), so it's better style to use "a = 3" in that > >context. >

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

Tim Peters wrote: To my eyes, this is genuinely harder to follow, despite its relative brevity: while total != (total := total + term): Not surprising, since there are at least two deeper levels of subtlety at play: 1. total isn't just naming a subexpression, it's being rebound to som

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

Tim Peters wrote: As a statement in a program (as opposed to typed at a shell), "a := 3" has the unnecessary (in that context) property of returning (and discarding 3), so it's better style to use "a = 3" in that context. That seems like a post-hoc justification. If := were the one and only ass

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Raymond Hettinger ] >>> After re-reading all the proposed code samples, I believe that >>> adopting the PEP will make the language harder to teach to people >>> who are not already software engineers. [Tim] >> Can you elaborate on that? [Raymond] > Just distinguishing between =, :=, and == will