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

On Sat, Apr 21, 2018 at 5:11 PM, Steven D'Aprano wrote: > On Sat, Apr 21, 2018 at 12:30:36PM +1000, Chris Angelico wrote: >> Introducing expression assignments will make these oddities even more >> obvious. You'd be able to demonstrate things like this at function >> scope,

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

On Sat, Apr 21, 2018 at 12:30:36PM +1000, Chris Angelico wrote: > There's that word "readability" again. Sometimes I wish the Zen of > Python didn't use it, because everyone seems to think that "readable" > means "code I like". In fairness, if one can't read code, then one can hardly be expected

Re: [Python-Dev] Introducing python.zulipchat.com

On 20 April 2018 at 22:52, Brett Cannon wrote: > As an experiment we have gotten an instance of Zulip running for Python's > development at https://python.zulipchat.com (IOW this is for discussing the > development of Python only). As Guido has put it you can view Zulip like >

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

On 21 April 2018 at 07:33, Tim Peters wrote: > I expected that, given that expressions "naturally nest", chained > targets could still be specified: > > a := b := c:= 5 > > but since they're all plain names there's no way to tell whether the > bindings occur "left to

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

On 21/04/18 08:46, Chris Angelico wrote: doubled_items = [x for x in (items := get_items()) if x * 2 in items] This will leak 'items' into the surrounding scope (but not 'x'). At the risk of stating the obvious - wasn't there work in Python 3 to prevent leakage from comprehensions ? [x for x

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

On 21 April 2018 at 17:11, Steven D'Aprano wrote: > So can you explain specifically what odd function-scope behaviour you > are referring to? Give an example please? Once we allow name binding as an expression, there are three main cases to consider in comprehensions: 1.

Re: [Python-Dev] Introducing python.zulipchat.com

OK, got there now. Thanks for the help. That's a lousy sign-up experience, though... Paul On 21 April 2018 at 09:55, Jonathan Goble wrote: > On Sat, Apr 21, 2018, 4:51 AM Paul Moore wrote: >> >> Just a usability note - the sign in procedure seems very

Re: [Python-Dev] Introducing python.zulipchat.com

On Sat, Apr 21, 2018, 4:51 AM Paul Moore wrote: > Just a usability note - the sign in procedure seems very weird. I > tried to log in, but didn't want to create another independent account > so I tried "Sign in with Google" and "Sign in with Github". Both took > me round a

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

On 21 April 2018 at 03:30, Chris Angelico wrote: > There's that word "readability" again. Sometimes I wish the Zen of > Python didn't use it, because everyone seems to think that "readable" > means "code I like". Readability is subjective, yes. But it's not the same as

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

On Sat, Apr 21, 2018 at 6:38 PM, Anthony Flury via Python-Dev wrote: > On 21/04/18 08:46, Chris Angelico wrote: >> >> doubled_items = [x for x in (items := get_items()) if x * 2 in items] >> >> This will leak 'items' into the surrounding scope (but not 'x'). > > At the risk

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

Tim Peters wrote: > [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 clearly before by Terry Reedy, but > it bears repeating :-)

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

On 21/04/18 11:18, Chris Angelico wrote: But you haven't answered anything about what "readable" means. Does it mean "if I look at this code, I can predict what dis.dis() would output"? Or does it mean "this code clearly expresses an algorithm and the programmer's intent"? Frequently I hear

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

It could also be postponed simply by saying assignment expressions follow the same semantics as other bindings in comprehensions... which are subject to change pending PEP (i.e. some different number). On the other hand, I am one who doesn't really care about assignment expressions in

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

Chris Angelico writes: > There's that word "readability" again. Sometimes I wish the Zen of > Python didn't use it, because everyone seems to think that "readable" > means "code I like". Hey, man, that hurts. Some of us not only *have* precise statements of the aspects of readability we

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

On Sat, Apr 21, 2018 at 7:12 PM, Paul Moore wrote: > On 21 April 2018 at 03:30, Chris Angelico wrote: >> There's that word "readability" again. Sometimes I wish the Zen of >> Python didn't use it, because everyone seems to think that "readable" >> means

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

It feels very strange that the PEP tries to do two almost entirely unrelated things. Assignment expressions are one thing, with merits and demerits discussed at length. But "fixing" comprehension scoping is pretty much completely orthogonal. Sure, it might be a good idea. And yes there are

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

On 22 April 2018 at 01:44, David Mertz wrote: > It feels very strange that the PEP tries to do two almost entirely unrelated > things. Assignment expressions are one thing, with merits and demerits > discussed at length. > > But "fixing" comprehension scoping is pretty much

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

On Sat, Apr 21, 2018 at 05:46:44PM +1000, Chris Angelico wrote: > On Sat, Apr 21, 2018 at 5:11 PM, Steven D'Aprano wrote: > > So can you explain specifically what odd function-scope behaviour you > > are referring to? Give an example please? > > doubled_items = [x for x in

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

On Sat, Apr 21, 2018 at 10:26 PM, Steven D'Aprano wrote: > On Sat, Apr 21, 2018 at 05:46:44PM +1000, Chris Angelico wrote: >> On Sat, Apr 21, 2018 at 5:11 PM, Steven D'Aprano wrote: > >> > So can you explain specifically what odd function-scope behaviour

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

On Sat, Apr 21, 2018 at 03:44:48PM +, David Mertz wrote: > It feels very strange that the PEP tries to do two almost entirely > unrelated things. Assignment expressions are one thing, with merits and > demerits discussed at length. > > But "fixing" comprehension scoping is pretty much

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

Tim Peters wrote: > [Christoph Groth ] > > Still, it seems weird to have two different ways of binding names in > > the language where one would be sufficient (i.e. the old one would > > remain only for backwards compatibility). From the point of view of > > someone

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

On Sat, Apr 21, 2018 at 08:35:51PM +0100, Matthew Woodcraft wrote: > Well, that's a reason to make the example a bit more realistic, then. > > Say: > > if match := re.search(pat1, text): > do_something_with(match.group(0)) > elif match := re.search(pat2, text): >

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

[Matthew Woodcraft] >>> Well, that's a reason to make the example a bit more realistic, then. >>> >>> Say: >>> >>> if match := re.search(pat1, text): >>> do_something_with(match.group(0)) >>> elif match := re.search(pat2, text): >>> do_something_else_with(match.group(0), match.group(1))

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

On 22 April 2018 at 02:31, Steven D'Aprano wrote: > This is not entirely unprecedented in Python: it is analogous > (although not identical) to binding default values to parameters: > > def running_total(items, total=total): > # Here total is local to the

Re: [Python-Dev] Introducing python.zulipchat.com

The Zulip project maintainers are active on our instance so after you join go to the Zulip stream and start a topic about this. On Sat, Apr 21, 2018, 02:16 Paul Moore, wrote: > OK, got there now. Thanks for the help. That's a lousy sign-up > experience, though... > Paul > >

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

Round 2 (Changed order, see below): 1. with open(fn) as f: # current behavior 2. with (open(fn) as f): # same 3. with closing(urlopen(url)) as dl: # current behavior 5. with (closing(urlopen(url)) as dl): # same 4. with

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

[Christoph Groth ] >> > Still, it seems weird to have two different ways of binding names in >> > the language where one would be sufficient (i.e. the old one would >> > remain only for backwards compatibility). From the point of view of >> > someone who's new to the

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

On Sat, Apr 21, 2018 at 6:13 PM, Steven D'Aprano wrote: > On Sat, Apr 21, 2018 at 08:35:51PM +0100, Matthew Woodcraft wrote: > > > Well, that's a reason to make the example a bit more realistic, then. > > > > Say: > > > > if match := re.search(pat1, text): > >

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

On Sun, Apr 22, 2018 at 12:04 PM, Mike Miller wrote: > Round 2 (Changed order, see below): > > 1. with open(fn) as f: # current behavior > 2. with (open(fn) as f): # same > > 3. with closing(urlopen(url)) as dl: # current

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

[Matthew Woodcraft ] > I would like to suggest one more motivating example for "Capturing > condition values": multiple regex matches with 'elif'. > > if match := re.search(pat1, text): > print("Found one:", match.group(0)) > elif match := re.search(pat2, text): >

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

On 2018-04-21 19:02, Tim Peters wrote: > [Matthew Woodcraft ] >> I would like to suggest one more motivating example for "Capturing >> condition values": multiple regex matches with 'elif'. >> >> if match := re.search(pat1, text): >> print("Found one:", match.group(0))

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

On Sun, Apr 22, 2018 at 12:45:36AM +1000, Chris Angelico wrote: > > The reason I want items to "leak" into the surrounding scope is mostly > > so that the initial value for it can be set with a simple assignment > > outside the comprehension: > > > > items = (1, 2, 3) > > [ ... items :=

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

On 2018-04-21, 07:46 GMT, Chris Angelico wrote: > doubled_items = [x for x in (items := get_items()) if x * 2 in > items] Aside from other concerns expressed elsewhere by other people, do you really like this? I know and agree that “readability” is a subjective term, but it is my firm

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

[Christoph Groth ] > Tim, thanks for this clear analysis. Here's the best use case of more > general assignment expressions that I can come up with (from real code > I'm currently working on): > > class Basis: > def __init__(self, parent, periods=()): >

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

[Tim] >> I expected that, given that expressions "naturally nest", chained >> targets could still be specified: >> >> a := b := c:= 5 >> >> but since they're all plain names there's no way to tell whether the >> bindings occur "left to right" or "right to left" short of staring at >> the

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

On 2018-04-17 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 would like to suggest one more motivating example for "Capturing condition values": multiple regex matches with 'elif'. if match

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

On 22 April 2018 at 03:41, Steven D'Aprano wrote: > We *already* have the rule that the outermost iterable is special, > except it isn't a rule precisely, since (as far as I know) it isn't > documented anywhere, nor was it ever planned as a feature. It's a deliberate feature