Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 03/23/2018 03:01 AM, Chris Angelico wrote: Apologies for letting this languish; life has an annoying habit of getting in the way now and then. My simple response to all of this is that it's not worth it. Each new example convinces me more and more that in almost every case, sublocal

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

This thread is dead. On Tue, Mar 27, 2018 at 5:40 PM, Rob Cliffe via Python-ideas < python-ideas@python.org> wrote: > > > On 28/03/2018 01:19, Steven D'Aprano wrote: > >> On Wed, Mar 28, 2018 at 12:08:24AM +0100, Rob Cliffe via Python-ideas >> wrote: >> >>> On 27/03/2018 16:22, Guido van Rossum

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 28/03/2018 01:19, Steven D'Aprano wrote: On Wed, Mar 28, 2018 at 12:08:24AM +0100, Rob Cliffe via Python-ideas wrote: On 27/03/2018 16:22, Guido van Rossum wrote: The standard reply here is that if you can't tell at a glance whether that's the case, your code is too complex. The Zen of

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Wed, Mar 28, 2018 at 12:08:24AM +0100, Rob Cliffe via Python-ideas wrote: > > On 27/03/2018 16:22, Guido van Rossum wrote: > >The standard reply here is that if you can't tell at a glance whether > >that's the case, your code is too complex. The Zen of Python says > >"Namespaces are one

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 27/03/2018 16:22, Guido van Rossum wrote: On Tue, Mar 27, 2018 at 7:00 AM, Nick Coghlan > wrote: On 27 March 2018 at 01:57, Guido van Rossum > wrote: > On Mon, Mar 26, 2018 at 7:57 AM,

[Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

> > ... From here, > the most important concern and question is: Is there any other syntax > or related proposal that ought to be mentioned here? I am not sure if this is valid, but perhaps this is an alternative syntax which might be simpler: ``name! expr`` So for example, instead of:

Re: [Python-ideas] Fixing class scope brainstorm

Guido van Rossum wrote: I do notice that we probably can't easily solve this using the existing closure machinery ("cells") because if we were to have cells in the class dict, it would confuse everything else that looks in the class namespace. Maybe it could be done with a new kind of cell

Re: [Python-ideas] Fixing class scope brainstorm

On Tue, Mar 27, 2018 at 11:51 AM, Ivan Levkivskyi wrote: > On 27 March 2018 at 19:43, Ethan Furman wrote: > >> On 03/27/2018 11:12 AM, Ivan Levkivskyi wrote: >> >>> On 27 March 2018 at 18:19, Guido van Rossum wrote: >>> >> >> Hm, so maybe we shouldn't

Re: [Python-ideas] Fixing class scope brainstorm

On 27 March 2018 at 19:47, Paul Moore wrote: > On 27 March 2018 at 19:43, Ethan Furman wrote: > > On 03/27/2018 11:12 AM, Ivan Levkivskyi wrote: > >> > >> On 27 March 2018 at 18:19, Guido van Rossum wrote: > > > >>> Hm, so maybe we shouldn't touch

Re: [Python-ideas] Fixing class scope brainstorm

On 27 March 2018 at 19:43, Ethan Furman wrote: > On 03/27/2018 11:12 AM, Ivan Levkivskyi wrote: > >> On 27 March 2018 at 18:19, Guido van Rossum wrote: >> > > Hm, so maybe we shouldn't touch lambda, but we can at least fix the scope >>> issues for comprehensions and genexprs.

Re: [Python-ideas] Fixing class scope brainstorm

On 27 March 2018 at 19:43, Ethan Furman wrote: > On 03/27/2018 11:12 AM, Ivan Levkivskyi wrote: >> >> On 27 March 2018 at 18:19, Guido van Rossum wrote: > >>> Hm, so maybe we shouldn't touch lambda, but we can at least fix the scope >>> issues for comprehensions and genexprs.

Re: [Python-ideas] Fixing class scope brainstorm

On Tue, Mar 27, 2018 at 11:43 AM, Ethan Furman wrote: > On 03/27/2018 11:12 AM, Ivan Levkivskyi wrote: > >> On 27 March 2018 at 18:19, Guido van Rossum wrote: >> > > Hm, so maybe we shouldn't touch lambda, but we can at least fix the scope >>> issues for comprehensions and

Re: [Python-ideas] Fixing class scope brainstorm

On 03/27/2018 11:12 AM, Ivan Levkivskyi wrote: On 27 March 2018 at 18:19, Guido van Rossum wrote: Hm, so maybe we shouldn't touch lambda, but we can at least fix the scope issues for comprehensions and genexprs. Removing the implicit function scope in comprehensions is something I wanted

Re: [Python-ideas] Fixing class scope brainstorm

On 27 March 2018 at 18:19, Guido van Rossum wrote: > On Tue, Mar 27, 2018 at 6:56 AM, Nick Coghlan wrote: > >> [...] The implicit functions used in the >> comprehension & generator expression cases are just potentially >> simpler to handle, as we don't care

Re: [Python-ideas] Fixing class scope brainstorm

On Tue, Mar 27, 2018 at 9:52 AM, Paul Moore wrote: > I'd actually like to see some real world use cases to get a feel for > whether this is even worth worrying about. (I'm not saying it isn't, > just that it's hard to get a feel for the importance based on > artificial

Re: [Python-ideas] Fixing class scope brainstorm

On Tue, Mar 27, 2018 at 6:56 AM, Nick Coghlan wrote: > [...] The implicit functions used in the > comprehension & generator expression cases are just potentially > simpler to handle, as we don't care about their API signatures, which > means we can freely pollute their APIs

Re: [Python-ideas] Fixing class scope brainstorm

On 27 March 2018 at 16:51, Joao S. O. Bueno wrote: > Well, there is an idiom to "keep everything as is", and work around > the current limitations: > > class A: >def b(): >x = 1 >d = [i + x for i in range(2)] >return locals() >

Re: [Python-ideas] Fixing class scope brainstorm

Well, there is an idiom to "keep everything as is", and work around the current limitations: class A: def b(): x = 1 d = [i + x for i in range(2)] return locals() locals().update(b()) del b Maybe if we could find a syntactic sugar for this idiom (with an abuse of

Re: [Python-ideas] Fixing class scope brainstorm

On 27 March 2018 at 15:32, Joao S. O. Bueno wrote: > Yes - but that would be the intention of the code beign written as in > your example - > > class C: > x = 1 > f = staticmethod(lambda: print(x)) > > While, the classic behavior can be attained by

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Tue, Mar 27, 2018 at 7:00 AM, Nick Coghlan wrote: > On 27 March 2018 at 01:57, Guido van Rossum wrote: > > On Mon, Mar 26, 2018 at 7:57 AM, Nick Coghlan > wrote: > >> By contrast, the sublocals idea strives to keep the *lifecycle*

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 2018-03-23 06:01, Chris Angelico wrote: > https://www.python.org/dev/peps/pep-0572/ > A suggestion: Under the rejected "Special-casing comprehensions", you show "prefix-local-name-bindings": Name bindings that appear before the loop, like: > stuff = [(y, x/y) where y = f(x) for x in

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On 03/25/2018 09:46 AM, Ethan Furman wrote: On 03/24/2018 09:24 PM, Nick Coghlan wrote: No, the fact that the expression defining the outermost iterable gets evaluated in the outer scope is behaviour that's explicitly tested for in the regression test suite. The language reference spells out

Re: [Python-ideas] Fixing class scope brainstorm

On 27 March 2018 at 10:56, Nick Coghlan wrote: > ... Making it so that lambdas > can close over class attributes breaks that equivalence, and if we > were to use the cell based approach I suggest above, the seams would > be visible in the case where a lambda expression

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On 27 March 2018 at 01:57, Guido van Rossum wrote: > On Mon, Mar 26, 2018 at 7:57 AM, Nick Coghlan wrote: >> By contrast, the sublocals idea strives to keep the *lifecycle* impact >> of naming a subexpression as negligible as possible - while a named >>

Re: [Python-ideas] Fixing class scope brainstorm

On 27 March 2018 at 01:11, Guido van Rossum wrote: > Honestly that sounds way too complex. In my ideal world, only functions > defined with 'def' are methods whose __get__ auto-binds the first argument > (unless @classmethod or @staticmethod is present), and do not get to "see"