Mailman 3 April 2018 - Python-ideas

Re: [Python-ideas] PEP 572: Assignment Expressions (post #4)
by Thautwarm Zhao 13 Apr '18

13 Apr '18

> You're looking at a very early commit there. I suggest looking at the > most recent commits on one of two branches: https://github.com/Rosuav/cpython/blob/statement-local- variables/Grammar/Grammar https://github.com/Rosuav/cpython/blob/assignment- expressions/Grammar/Grammar > Those are the two most recent states in my progress towards (a) > statement-local name bindings with "EXPR as NAME", and (b) assignment > expressions with "target := value". Okay, and the syntax "target := value" seems to be much easier to handle with. I do support this feature, but now I'm worried about the meaning of ':=', it seems to be a lazy assignment in some degree. I'm not sure using ':=' is proper here. > Inasmuch as I might like assignment expressions, it would only be in while or if statements, personally. Not exactly, assignment expression also works for "if expression", we can now have null checking. var.method() if var:= function() else None Null checking is importance enough to have a specific syntax in many other languages(C#, kotlin, Ruby and so on), and we can even have more than null checking by adding expression assignment.

10 18

PEP 573: Module State Access from C Extension Methods
by Marcel Plch 13 Apr '18

13 Apr '18

I have prepared a PEP for better support of PEP 489 multiphase initialization. It makes it possible for extension types, their methods to be more specific, to access the state of the module they are defined in. conversation - https://mail.python.org/pipermail/import-sig/2015-July/001022.html PEP - https://github.com/python/peps/blob/master/pep-0573.rst Implementation - https://github.com/Traceur759/cpython/pull/4

1 0

Re: [Python-ideas] PEP 572: Assignment Expressions (post #4)
by Thautwarm Zhao 12 Apr '18

12 Apr '18

> > Makes sense. However, couldn't you prevent that by giving with > priority over the binding ? As in "(with simple_cm) as value", where > > we consider the "as" as binding operator instead of part of the with > > statement ? Sure, you could commit suicide by parenthesis, but by > > default it'd do exactly what the "with simple_cm as value" currently > > does. This does require use of as instead of :=, though. (which was > > the point I was trying to make, apologies for the confusion) > > Does "(with simple_cm) as value" means "with (simple_cm as value)"? > If so, it's impossible to let the priority of "with ... as ..." over `as` binding. > > This is the grammar of current syntax related to with statement: > > with_stmt: 'with' with_item (',' with_item)* ':' suite > with_item: test ['as' expr] > > If `as` binding could be used in a general expression, just as > `test` is the top of expression, an expression using `as` binding must be in the structure > `test`. > In other words, if you write > > with expr as name: > # do stuff > > Without doubt it's equivalent to `with (expr as name)`. > > Or you want to completely change the grammar design of CPython :) > > thautwarm Additionally, here is an evidence. I've just had a look at Chris Angelico's implementation about expression assignment, it's cool, however the problem is still raised. https://github.com/Rosuav/cpython/blob/0f237048b7665720b5165a40de0ed601c1e8… `as` binding is added at line 111, obviously you cannot separate it from the `test` structure(because `test` is the top expr). testlist_comp: (test|star_expr) ( comp_for | 'as' NAME | (',' (test|star_expr))* [','] ) It seems that if we're to support expression assignment, `as` binding should be declined. To be honest I feel upset because I think `expr as name` is really cool and pythonic. thautwarm 2018-04-13 1:35 GMT+08:00 Thautwarm Zhao <yaoxiansamma(a)gmail.com>: > > Makes sense. However, couldn't you prevent that by giving with > > priority over the binding ? As in "(with simple_cm) as value", where > > we consider the "as" as binding operator instead of part of the with > > statement ? Sure, you could commit suicide by parenthesis, but by > > default it'd do exactly what the "with simple_cm as value" currently > > does. This does require use of as instead of :=, though. (which was > > the point I was trying to make, apologies for the confusion) > > Does "(with simple_cm) as value" means "with (simple_cm as value)"? > If so, it's impossible to let the priority of "with ... as ..." over `as` > binding. > > This is the grammar of current syntax related to with statement: > > with_stmt: 'with' with_item (',' with_item)* ':' suite > with_item: test ['as' expr] > > If `as` binding could be used in a general expression, just as > `test` is the top of expression, an expression using `as` binding must be > in the structure `test`. > In other words, if you write > > with expr as name: > # do stuff > > Without doubt it's equivalent to `with (expr as name)`. > > Or you want to completely change the grammar design of CPython :) > > thautwarm > > > > 2018-04-12 21:41 GMT+08:00 <python-ideas-request(a)python.org>: > >> Send Python-ideas mailing list submissions to >> python-ideas(a)python.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://mail.python.org/mailman/listinfo/python-ideas >> or, via email, send a message with subject or body 'help' to >> python-ideas-request(a)python.org >> >> You can reach the person managing the list at >> python-ideas-owner(a)python.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Python-ideas digest..." >> >> Today's Topics: >> >> 1. Re: PEP 572: Assignment Expressions (post #4) (Chris Angelico) >> 2. Re: PEP 572: Assignment Expressions (post #4) (Chris Angelico) >> 3. Re: PEP 572: Assignment Expressions (post #4) (Nick Coghlan) >> 4. Re: PEP 572: Assignment Expressions (post #4) (Jacco van Dorp) >> 5. Re: PEP 572: Assignment Expressions (post #4) (Chris Angelico) >> >> >> ---------- 已转发邮件 ---------- >> From: Chris Angelico <rosuav(a)gmail.com> >> To: python-ideas <python-ideas(a)python.org> >> Cc: >> Bcc: >> Date: Thu, 12 Apr 2018 23:08:06 +1000 >> Subject: Re: [Python-ideas] PEP 572: Assignment Expressions (post #4) >> On Thu, Apr 12, 2018 at 9:09 PM, Paul Moore <p.f.moore(a)gmail.com> wrote: >> > On 11 April 2018 at 22:28, Chris Angelico <rosuav(a)gmail.com> wrote: >> >> On Thu, Apr 12, 2018 at 1:22 AM, Nick Coghlan <ncoghlan(a)gmail.com> >> wrote: >> >>> This argument will be strengthened by making the examples used in the >> >>> PEP itself more attractive, as well as proposing suitable additions to >> >>> PEP 8, such as: >> >>> >> >>> 1. If either assignment statements or assignment expressions can be >> >>> used, prefer statements >> >>> 2. If using assignment expressions would lead to ambiguity about >> >>> execution order, restructure to use statements instead >> >> >> >> Fair enough. Also adding that chained assignment expressions should >> >> generally be avoided. >> > >> > Another one I think should be included (I'm a bit sad that it's not so >> > obvious that no-one would ever even think of it, but the current >> > discussion pretty much killed that hope for me). >> > >> > * Assignment expressions should never be used standalone - assignment >> > statements should *always* be used in that case. >> >> That's covered by the first point. If it's a standalone statement, >> then the statement form could be used, ergo you should prefer the >> statement form. >> >> ChrisA >> >> >> >> ---------- 已转发邮件 ---------- >> From: Chris Angelico <rosuav(a)gmail.com> >> To: python-ideas <python-ideas(a)python.org> >> Cc: >> Bcc: >> Date: Thu, 12 Apr 2018 23:14:34 +1000 >> Subject: Re: [Python-ideas] PEP 572: Assignment Expressions (post #4) >> On Thu, Apr 12, 2018 at 7:21 PM, Kirill Balunov <kirillbalunov(a)gmail.com> >> wrote: >> > >> > I gain readability! I don't see any reason to use it in other >> contexts... >> > Because it makes the code unreadable and difficult to perceive while >> giving >> > not so much benefit. I may be wrong, but so far I have not seen a >> single >> > example that at least slightly changed my mind. >> >> This is, in effect, your entire argument for permitting assignments >> only in certain contexts. "I can't think of any useful reason for >> doing this, so we shouldn't do it". But that means making the language >> grammar more complicated (both in the technical sense of the parser's >> definitions, and in the colloquial sense of how you'd explain Python >> to a new programmer), because there are these magic constructs that >> can be used anywhere in an expression, but ONLY if that expression is >> inside an if or while statement. You lose the ability to refactor your >> code simply to satisfy an arbitrary restriction to appease someone's >> feeling of "it can't be useful anywhere else". >> >> There are basically two clean ways to do this: >> >> 1) Create actual syntax as part of the while statement, in the same >> way that the 'with EXPR as NAME:' statement does. This means you >> cannot put any additional operators after the 'as NAME' part. It's as >> much a part of the statement's syntax as the word 'in' is in a for >> loop. >> >> 2) Make this a feature of expressions in general. Then they can be >> used anywhere that an expression can be. >> >> I've gone for option 2. If you want to push for option 1, go ahead, >> but it's a nerfed solution just because you personally cannot think of >> any good use for this. >> >> ChrisA >> >> >> >> ---------- 已转发邮件 ---------- >> From: Nick Coghlan <ncoghlan(a)gmail.com> >> To: Chris Angelico <rosuav(a)gmail.com> >> Cc: python-ideas <python-ideas(a)python.org> >> Bcc: >> Date: Thu, 12 Apr 2018 23:19:59 +1000 >> Subject: Re: [Python-ideas] PEP 572: Assignment Expressions (post #4) >> On 12 April 2018 at 07:28, Chris Angelico <rosuav(a)gmail.com> wrote: >> > On Thu, Apr 12, 2018 at 1:22 AM, Nick Coghlan <ncoghlan(a)gmail.com> >> wrote: >> >>> Frequently Raised Objections >> >>> ============================ >> >> >> >> There needs to be a subsection here regarding the need to call `del` >> >> at class and module scope, just as there is for loop iteration >> >> variables at those scopes. >> > >> > Hmm, I'm not sure I follow. Are you saying that this is an objection >> > to assignment expressions, or an objection to them not being >> > statement-local? If the latter, it's really more about "rejected >> > alternative proposals". >> >> It's both - accidentally polluting class and module namespaces is an >> argument against expression level assignments in general, and sublocal >> namespaces aimed to eliminate that downside. >> >> Since feedback on the earlier versions of the PEP has moved sublocal >> namespaces into the "rejected due to excessive conceptual complexity" >> box, that means accidental namespace pollution comes back as a >> downside that the PEP should mention. >> >> I don't think it needs to say much, just point out that they share the >> downside of regular for loops: if you use one at class or module >> scope, and don't want to export the name, you need to delete it >> explicitly. >> >> Cheers, >> Nick. >> >> -- >> Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia >> >> >> >> ---------- 已转发邮件 ---------- >> From: Jacco van Dorp <j.van.dorp(a)deonet.nl> >> To: python-ideas <python-ideas(a)python.org> >> Cc: >> Bcc: >> Date: Thu, 12 Apr 2018 15:31:59 +0200 >> Subject: Re: [Python-ideas] PEP 572: Assignment Expressions (post #4) >> 2018-04-12 15:02 GMT+02:00 Nick Coghlan <ncoghlan(a)gmail.com>: >> > On 12 April 2018 at 22:22, Jacco van Dorp <j.van.dorp(a)deonet.nl> wrote: >> >> I've looked through PEP 343, contextlib docs ( >> >> https://docs.python.org/3/library/contextlib.html ), and I couldn't >> >> find a single case where "with (y := f(x))" would be invalid. >> > >> > Consider this custom context manager: >> > >> > @contextmanager >> > def simple_cm(): >> > yield 42 >> > >> > Given that example, the following code: >> > >> > with cm := simple_cm() as value: >> > print(cm.func.__name__, value) >> > >> > would print "'simple_cm 42", since the assignment expression would >> > reference the context manager itself, while the with statement binds >> > the yielded value. >> > >> > Another relevant example would be `contextlib.closing`: that returns >> > the passed in argument from __enter__, *not* self. >> > >> > And that's why earlier versions of PEP 572 (which used the "EXPR as >> > NAME" spelling) just flat out prohibited top level name binding >> > expressions in with statements: "with (expr as name):" and "with expr >> > as name:" were far too different semantically for the only syntactic >> > difference to be a surrounding set of parentheses. >> > >> > Cheers, >> > Nick. >> >> Makes sense. However, couldn't you prevent that by giving with >> priority over the binding ? As in "(with simple_cm) as value", where >> we consider the "as" as binding operator instead of part of the with >> statement ? Sure, you could commit suicide by parenthesis, but by >> default it'd do exactly what the "with simple_cm as value" currently >> does. This does require use of as instead of :=, though. (which was >> the point I was trying to make, apologies for the confusion) >> >> >> >> ---------- 已转发邮件 ---------- >> From: Chris Angelico <rosuav(a)gmail.com> >> To: python-ideas <python-ideas(a)python.org> >> Cc: >> Bcc: >> Date: Thu, 12 Apr 2018 23:41:49 +1000 >> Subject: Re: [Python-ideas] PEP 572: Assignment Expressions (post #4) >> On Thu, Apr 12, 2018 at 11:31 PM, Jacco van Dorp <j.van.dorp(a)deonet.nl> >> wrote: >> > 2018-04-12 15:02 GMT+02:00 Nick Coghlan <ncoghlan(a)gmail.com>: >> >> On 12 April 2018 at 22:22, Jacco van Dorp <j.van.dorp(a)deonet.nl> >> wrote: >> >>> I've looked through PEP 343, contextlib docs ( >> >>> https://docs.python.org/3/library/contextlib.html ), and I couldn't >> >>> find a single case where "with (y := f(x))" would be invalid. >> >> >> >> Consider this custom context manager: >> >> >> >> @contextmanager >> >> def simple_cm(): >> >> yield 42 >> >> >> >> Given that example, the following code: >> >> >> >> with cm := simple_cm() as value: >> >> print(cm.func.__name__, value) >> >> >> >> would print "'simple_cm 42", since the assignment expression would >> >> reference the context manager itself, while the with statement binds >> >> the yielded value. >> >> >> >> Another relevant example would be `contextlib.closing`: that returns >> >> the passed in argument from __enter__, *not* self. >> >> >> >> And that's why earlier versions of PEP 572 (which used the "EXPR as >> >> NAME" spelling) just flat out prohibited top level name binding >> >> expressions in with statements: "with (expr as name):" and "with expr >> >> as name:" were far too different semantically for the only syntactic >> >> difference to be a surrounding set of parentheses. >> >> >> >> Cheers, >> >> Nick. >> > >> > Makes sense. However, couldn't you prevent that by giving with >> > priority over the binding ? As in "(with simple_cm) as value", where >> > we consider the "as" as binding operator instead of part of the with >> > statement ? Sure, you could commit suicide by parenthesis, but by >> > default it'd do exactly what the "with simple_cm as value" currently >> > does. This does require use of as instead of :=, though. (which was >> > the point I was trying to make, apologies for the confusion) >> >> If you want this to be a generic name-binding operation, then no; most >> objects cannot be used as context managers. You'll get an exception if >> you try to use "with 1 as x:", for instance. >> >> As Nick mentioned, there are context managers that return something >> other than 'self', and for those, "with expr as name:" has an >> important meaning that cannot easily be captured with an assignment >> operator. >> >> ChrisA >> >> >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas(a)python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> >> >

2 1

Re: [Python-ideas] Python-ideas Digest, Vol 137, Issue 67
by Thautwarm Zhao 12 Apr '18

12 Apr '18

> Makes sense. However, couldn't you prevent that by giving with > priority over the binding ? As in "(with simple_cm) as value", where > we consider the "as" as binding operator instead of part of the with > statement ? Sure, you could commit suicide by parenthesis, but by > default it'd do exactly what the "with simple_cm as value" currently > does. This does require use of as instead of :=, though. (which was > the point I was trying to make, apologies for the confusion) Does "(with simple_cm) as value" means "with (simple_cm as value)"? If so, it's impossible to let the priority of "with ... as ..." over `as` binding. This is the grammar of current syntax related to with statement: with_stmt: 'with' with_item (',' with_item)* ':' suite with_item: test ['as' expr] If `as` binding could be used in a general expression, just as `test` is the top of expression, an expression using `as` binding must be in the structure `test`. In other words, if you write with expr as name: # do stuff Without doubt it's equivalent to `with (expr as name)`. Or you want to completely change the grammar design of CPython :) thautwarm 2018-04-12 21:41 GMT+08:00 <python-ideas-request(a)python.org>: > Send Python-ideas mailing list submissions to > python-ideas(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/python-ideas > or, via email, send a message with subject or body 'help' to > python-ideas-request(a)python.org > > You can reach the person managing the list at > python-ideas-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-ideas digest..." > > Today's Topics: > > 1. Re: PEP 572: Assignment Expressions (post #4) (Chris Angelico) > 2. Re: PEP 572: Assignment Expressions (post #4) (Chris Angelico) > 3. Re: PEP 572: Assignment Expressions (post #4) (Nick Coghlan) > 4. Re: PEP 572: Assignment Expressions (post #4) (Jacco van Dorp) > 5. Re: PEP 572: Assignment Expressions (post #4) (Chris Angelico) > > > ---------- 已转发邮件 ---------- > From: Chris Angelico <rosuav(a)gmail.com> > To: python-ideas <python-ideas(a)python.org> > Cc: > Bcc: > Date: Thu, 12 Apr 2018 23:08:06 +1000 > Subject: Re: [Python-ideas] PEP 572: Assignment Expressions (post #4) > On Thu, Apr 12, 2018 at 9:09 PM, Paul Moore <p.f.moore(a)gmail.com> wrote: > > On 11 April 2018 at 22:28, Chris Angelico <rosuav(a)gmail.com> wrote: > >> On Thu, Apr 12, 2018 at 1:22 AM, Nick Coghlan <ncoghlan(a)gmail.com> > wrote: > >>> This argument will be strengthened by making the examples used in the > >>> PEP itself more attractive, as well as proposing suitable additions to > >>> PEP 8, such as: > >>> > >>> 1. If either assignment statements or assignment expressions can be > >>> used, prefer statements > >>> 2. If using assignment expressions would lead to ambiguity about > >>> execution order, restructure to use statements instead > >> > >> Fair enough. Also adding that chained assignment expressions should > >> generally be avoided. > > > > Another one I think should be included (I'm a bit sad that it's not so > > obvious that no-one would ever even think of it, but the current > > discussion pretty much killed that hope for me). > > > > * Assignment expressions should never be used standalone - assignment > > statements should *always* be used in that case. > > That's covered by the first point. If it's a standalone statement, > then the statement form could be used, ergo you should prefer the > statement form. > > ChrisA > > > > ---------- 已转发邮件 ---------- > From: Chris Angelico <rosuav(a)gmail.com> > To: python-ideas <python-ideas(a)python.org> > Cc: > Bcc: > Date: Thu, 12 Apr 2018 23:14:34 +1000 > Subject: Re: [Python-ideas] PEP 572: Assignment Expressions (post #4) > On Thu, Apr 12, 2018 at 7:21 PM, Kirill Balunov <kirillbalunov(a)gmail.com> > wrote: > > > > I gain readability! I don't see any reason to use it in other contexts... > > Because it makes the code unreadable and difficult to perceive while > giving > > not so much benefit. I may be wrong, but so far I have not seen a single > > example that at least slightly changed my mind. > > This is, in effect, your entire argument for permitting assignments > only in certain contexts. "I can't think of any useful reason for > doing this, so we shouldn't do it". But that means making the language > grammar more complicated (both in the technical sense of the parser's > definitions, and in the colloquial sense of how you'd explain Python > to a new programmer), because there are these magic constructs that > can be used anywhere in an expression, but ONLY if that expression is > inside an if or while statement. You lose the ability to refactor your > code simply to satisfy an arbitrary restriction to appease someone's > feeling of "it can't be useful anywhere else". > > There are basically two clean ways to do this: > > 1) Create actual syntax as part of the while statement, in the same > way that the 'with EXPR as NAME:' statement does. This means you > cannot put any additional operators after the 'as NAME' part. It's as > much a part of the statement's syntax as the word 'in' is in a for > loop. > > 2) Make this a feature of expressions in general. Then they can be > used anywhere that an expression can be. > > I've gone for option 2. If you want to push for option 1, go ahead, > but it's a nerfed solution just because you personally cannot think of > any good use for this. > > ChrisA > > > > ---------- 已转发邮件 ---------- > From: Nick Coghlan <ncoghlan(a)gmail.com> > To: Chris Angelico <rosuav(a)gmail.com> > Cc: python-ideas <python-ideas(a)python.org> > Bcc: > Date: Thu, 12 Apr 2018 23:19:59 +1000 > Subject: Re: [Python-ideas] PEP 572: Assignment Expressions (post #4) > On 12 April 2018 at 07:28, Chris Angelico <rosuav(a)gmail.com> wrote: > > On Thu, Apr 12, 2018 at 1:22 AM, Nick Coghlan <ncoghlan(a)gmail.com> > wrote: > >>> Frequently Raised Objections > >>> ============================ > >> > >> There needs to be a subsection here regarding the need to call `del` > >> at class and module scope, just as there is for loop iteration > >> variables at those scopes. > > > > Hmm, I'm not sure I follow. Are you saying that this is an objection > > to assignment expressions, or an objection to them not being > > statement-local? If the latter, it's really more about "rejected > > alternative proposals". > > It's both - accidentally polluting class and module namespaces is an > argument against expression level assignments in general, and sublocal > namespaces aimed to eliminate that downside. > > Since feedback on the earlier versions of the PEP has moved sublocal > namespaces into the "rejected due to excessive conceptual complexity" > box, that means accidental namespace pollution comes back as a > downside that the PEP should mention. > > I don't think it needs to say much, just point out that they share the > downside of regular for loops: if you use one at class or module > scope, and don't want to export the name, you need to delete it > explicitly. > > Cheers, > Nick. > > -- > Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia > > > > ---------- 已转发邮件 ---------- > From: Jacco van Dorp <j.van.dorp(a)deonet.nl> > To: python-ideas <python-ideas(a)python.org> > Cc: > Bcc: > Date: Thu, 12 Apr 2018 15:31:59 +0200 > Subject: Re: [Python-ideas] PEP 572: Assignment Expressions (post #4) > 2018-04-12 15:02 GMT+02:00 Nick Coghlan <ncoghlan(a)gmail.com>: > > On 12 April 2018 at 22:22, Jacco van Dorp <j.van.dorp(a)deonet.nl> wrote: > >> I've looked through PEP 343, contextlib docs ( > >> https://docs.python.org/3/library/contextlib.html ), and I couldn't > >> find a single case where "with (y := f(x))" would be invalid. > > > > Consider this custom context manager: > > > > @contextmanager > > def simple_cm(): > > yield 42 > > > > Given that example, the following code: > > > > with cm := simple_cm() as value: > > print(cm.func.__name__, value) > > > > would print "'simple_cm 42", since the assignment expression would > > reference the context manager itself, while the with statement binds > > the yielded value. > > > > Another relevant example would be `contextlib.closing`: that returns > > the passed in argument from __enter__, *not* self. > > > > And that's why earlier versions of PEP 572 (which used the "EXPR as > > NAME" spelling) just flat out prohibited top level name binding > > expressions in with statements: "with (expr as name):" and "with expr > > as name:" were far too different semantically for the only syntactic > > difference to be a surrounding set of parentheses. > > > > Cheers, > > Nick. > > Makes sense. However, couldn't you prevent that by giving with > priority over the binding ? As in "(with simple_cm) as value", where > we consider the "as" as binding operator instead of part of the with > statement ? Sure, you could commit suicide by parenthesis, but by > default it'd do exactly what the "with simple_cm as value" currently > does. This does require use of as instead of :=, though. (which was > the point I was trying to make, apologies for the confusion) > > > > ---------- 已转发邮件 ---------- > From: Chris Angelico <rosuav(a)gmail.com> > To: python-ideas <python-ideas(a)python.org> > Cc: > Bcc: > Date: Thu, 12 Apr 2018 23:41:49 +1000 > Subject: Re: [Python-ideas] PEP 572: Assignment Expressions (post #4) > On Thu, Apr 12, 2018 at 11:31 PM, Jacco van Dorp <j.van.dorp(a)deonet.nl> > wrote: > > 2018-04-12 15:02 GMT+02:00 Nick Coghlan <ncoghlan(a)gmail.com>: > >> On 12 April 2018 at 22:22, Jacco van Dorp <j.van.dorp(a)deonet.nl> wrote: > >>> I've looked through PEP 343, contextlib docs ( > >>> https://docs.python.org/3/library/contextlib.html ), and I couldn't > >>> find a single case where "with (y := f(x))" would be invalid. > >> > >> Consider this custom context manager: > >> > >> @contextmanager > >> def simple_cm(): > >> yield 42 > >> > >> Given that example, the following code: > >> > >> with cm := simple_cm() as value: > >> print(cm.func.__name__, value) > >> > >> would print "'simple_cm 42", since the assignment expression would > >> reference the context manager itself, while the with statement binds > >> the yielded value. > >> > >> Another relevant example would be `contextlib.closing`: that returns > >> the passed in argument from __enter__, *not* self. > >> > >> And that's why earlier versions of PEP 572 (which used the "EXPR as > >> NAME" spelling) just flat out prohibited top level name binding > >> expressions in with statements: "with (expr as name):" and "with expr > >> as name:" were far too different semantically for the only syntactic > >> difference to be a surrounding set of parentheses. > >> > >> Cheers, > >> Nick. > > > > Makes sense. However, couldn't you prevent that by giving with > > priority over the binding ? As in "(with simple_cm) as value", where > > we consider the "as" as binding operator instead of part of the with > > statement ? Sure, you could commit suicide by parenthesis, but by > > default it'd do exactly what the "with simple_cm as value" currently > > does. This does require use of as instead of :=, though. (which was > > the point I was trying to make, apologies for the confusion) > > If you want this to be a generic name-binding operation, then no; most > objects cannot be used as context managers. You'll get an exception if > you try to use "with 1 as x:", for instance. > > As Nick mentioned, there are context managers that return something > other than 'self', and for those, "with expr as name:" has an > important meaning that cannot easily be captured with an assignment > operator. > > ChrisA > > > _______________________________________________ > Python-ideas mailing list > Python-ideas(a)python.org > https://mail.python.org/mailman/listinfo/python-ideas > >

1 0

Default values in multi-target assignment
by Serhiy Storchaka 12 Apr '18

12 Apr '18

Yet one crazy idea. What if allow default values for targets in multi-target assignment? >>> (a, b=0) = (1, 2) >>> a, b (1, 2) >>> (a, b=0) = (1,) >>> a, b (1, 0) >>> (a, b=0) = () Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: not enough values to unpack (expected at least 1, got 0) >>> (a, b=0) = (1, 2, 3) Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: too many values to unpack (expected at most 2) Currently you need either explicitly check the length of the right-hand part (if it is a sequence and not an arbitrary iterator), if len(c) == 1: a, = c b = 0 elif len(c) == 2: a, b = c else: raise TypeError or use an intermediate function: def f(a, b=0): return a, b a, b = f(*c) The latter can be written as an ugly one-liner: a, b = (lambda a, b=0: (a, b))(*c)

3 3

Re: [Python-ideas] Add the method decorator
by Jeroen Demeyer 12 Apr '18

12 Apr '18

On 2018-04-12 15:57, Serhiy Storchaka wrote: > There is a difference between functions implemented in Python and C. > Functions implemented in Python are descriptors. They can be used for > defining methods in Python classes. Functions implemented in C are not > descriptors. When set a class attribute to a functions implemented in C, > it will not become a bound method. As it happens, the recently-created PEP 575 allows creating functions in C which behave more like Python functions. It doesn't fix your use case with existing functions implemented in C or arbitrary callables but PEP 575 would fix your use case for user-implemented C functions.

1 0

Add the method decorator
by Serhiy Storchaka 12 Apr '18

12 Apr '18

There is a difference between functions implemented in Python and C. Functions implemented in Python are descriptors. They can be used for defining methods in Python classes. Functions implemented in C are not descriptors. When set a class attribute to a functions implemented in C, it will not become a bound method. from _noddy import noddy_name class Noddy: name = noddy_name noddy = Noddy() If noddy_name is a Python function, noddy.name() will call noddy_name(noddy), but if it is a C function, noddy.name() will call noddy_name(). The same is true for classes and custom callables. If a function is a descriptor, it can be converted into non-descriptor function by wrapping it with the staticmethod decorator. I suggest to add the method decorator, which converts an rbitrary callable into a descriptor. class Noddy: name = method(noddy_name) This will help to implement only performance critical method of a class in C. Currently you need to implement a base class in C, and inherit Python class from C class. But this doesn't work when the class should be inherited from other C class, or when an existing class should be patched like in total_ordering. This will help also to use custom callables as methods.

2 1

Proposal: flatten multi-nested list/tuple/set and other certain class/type.
by delta114514 12 Apr '18

12 Apr '18

I thought that itertools.chain.from_iterable isn't useful. cuz this only allow "single-nested iterable -- this will raise error when arg has non-nested element--" like below:: >>> from itertools import chain >>> chain.from_iterable([1]) <itertools.chain object at 0x00000112D332BF98> >>> list(_) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'int' object is not iterable and this can't unpack over double nest. >>> chain.from_iterable([[[1, 2]], [[4, 5]]]) <itertools.chain object at 0x00000112D3330B00> >>> list(_) [[1, 2], [4, 5]] So, I wanted to make "True chain.from_iterable". and this is it. def flatten(iterables, unpack=(list, tuple, set), peep=(list, tuple, set)): for element in iterables: try: if isinstance(element, unpack): if isinstance(element, peep): yield from flatten(element, unpack=unpack, peep=peep) else: yield from flatten(element, unpack=(), peep=()) elif isinstance(element, peep): yield type(element)(flatten(element, unpack=unpack, peep=peep)) else: raise TypeError except TypeError: yield element Reason why I didin't use type() is wanted to unpack type-object like "range" and I wanted to unpack user-defined-class/func. this is why I didin't use collections.Iterable to check instance. I know this will be destructed by itertools.count :( Please give me advice. And I wanna know why function like this is not in standard library. thx.

1 0

flatten multi-nested list/set/tuple and certain types.
by delta114514 12 Apr '18

12 Apr '18

I thought that itertools.chain.from_iterable isn't useful. cuz this only allow "single-nested iterable -- this will raise error when arg has non-nested element--" like below:: >>> from itertools import chain >>> chain.from_iterable([1]) <itertools.chain object at 0x00000112D332BF98> >>> list(_) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'int' object is not iterable and this can't unpack over double nest. >>> chain.from_iterable([[[1, 2]], [[4, 5]]]) <itertools.chain object at 0x00000112D3330B00> >>> list(_) [[1, 2], [4, 5]] So, I wanted to make "True chain.from_iterable". and this is it. def flatten(iterables, unpack=(list, tuple, set), peep=(list, tuple, set)): for element in iterables: try: if isinstance(element, unpack): if isinstance(element, peep): yield from flatten(element, unpack=unpack, peep=peep) else: yield from flatten(element, unpack=(), peep=()) elif isinstance(element, peep): yield type(element)(flatten(element, unpack=unpack, peep=peep)) else: raise TypeError except TypeError: yield element Reason why I didin't use type() is wanted to unpack type-object like "range" and I wanted to unpack user-defined-class/func. this is why I didin't use collections.Iterable to check instance. I know this will be destructed by itertools.count :( Please give me advice. And I wanna know why function like this is not in standard library. thx.

1 0

PEP 572: Statement-Local Name Bindings, take three!
by Chris Angelico 11 Apr '18

11 Apr '18

Apologies for letting this languish; life has an annoying habit of getting in the way now and then. Feedback from the previous rounds has been incorporated. From here, the most important concern and question is: Is there any other syntax or related proposal that ought to be mentioned here? If this proposal is rejected, it should be rejected with a full set of alternatives. Text of PEP is below; formatted version will be live shortly (if it isn't already) at: https://www.python.org/dev/peps/pep-0572/ ChrisA PEP: 572 Title: Syntax for Statement-Local Name Bindings Author: Chris Angelico <rosuav(a)gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 28-Feb-2018 Python-Version: 3.8 Post-History: 28-Feb-2018, 02-Mar-2018, 23-Mar-2018 Abstract ======== Programming is all about reusing code rather than duplicating it. When an expression needs to be used twice in quick succession but never again, it is convenient to assign it to a temporary name with small scope. By permitting name bindings to exist within a single statement only, we make this both convenient and safe against name collisions. Rationale ========= When a subexpression is used multiple times in a list comprehension, there are currently several ways to spell this, none of which is universally accepted as ideal. A statement-local name allows any subexpression to be temporarily captured and then used multiple times. Additionally, this syntax can in places be used to remove the need to write an infinite loop with a ``break`` in it. Capturing part of a ``while`` loop's condition can improve the clarity of the loop header while still making the actual value available within the loop body. Syntax and semantics ==================== In any context where arbitrary Python expressions can be used, a **named expression** can appear. This must be parenthesized for clarity, and is of the form ``(expr as NAME)`` where ``expr`` is any valid Python expression, and ``NAME`` is a simple name. The value of such a named expression is the same as the incorporated expression, with the additional side-effect that NAME is bound to that value for the remainder of the current statement. Just as function-local names shadow global names for the scope of the function, statement-local names shadow other names for that statement. (They can technically also shadow each other, though actually doing this should not be encouraged.) Assignment to statement-local names is ONLY through this syntax. Regular assignment to the same name will remove the statement-local name and affect the name in the surrounding scope (function, class, or module). Statement-local names never appear in locals() or globals(), and cannot be closed over by nested functions. Execution order and its consequences ------------------------------------ Since the statement-local name binding lasts from its point of execution to the end of the current statement, this can potentially cause confusion when the actual order of execution does not match the programmer's expectations. Some examples:: # A simple statement ends at the newline or semicolon. a = (1 as y) print(y) # NameError # The assignment ignores the SLNB - this adds one to 'a' a = (a + 1 as a) # Compound statements usually enclose everything... if (re.match(...) as m): print(m.groups(0)) print(m) # NameError # ... except when function bodies are involved... if (input("> ") as cmd): def run_cmd(): print("Running command", cmd) # NameError # ... but function *headers* are executed immediately if (input("> ") as cmd): def run_cmd(cmd=cmd): # Capture the value in the default arg print("Running command", cmd) # Works Function bodies, in this respect, behave the same way they do in class scope; assigned names are not closed over by method definitions. Defining a function inside a loop already has potentially-confusing consequences, and SLNBs do not materially worsen the existing situation. Differences from regular assignment statements ---------------------------------------------- Using ``(EXPR as NAME)`` is similar to ``NAME = EXPR``, but has a number of important distinctions. * Assignment is a statement; an SLNB is an expression whose value is the same as the object bound to the new name. * SLNBs disappear at the end of their enclosing statement, at which point the name again refers to whatever it previously would have. SLNBs can thus shadow other names without conflict (although deliberately doing so will often be a sign of bad code). * SLNBs cannot be closed over by nested functions, and are completely ignored for this purpose. * SLNBs do not appear in ``locals()`` or ``globals()``. * An SLNB cannot be the target of any form of assignment, including augmented. Attempting to do so will remove the SLNB and assign to the fully-scoped name. In many respects, an SLNB is akin to a local variable in an imaginary nested function, except that the overhead of creating and calling a function is bypassed. As with names bound by ``for`` loops inside list comprehensions, SLNBs cannot "leak" into their surrounding scope. Example usage ============= These list comprehensions are all approximately equivalent:: # Calling the function twice stuff = [[f(x), x/f(x)] for x in range(5)] # External helper function def pair(x, value): return [value, x/value] stuff = [pair(x, f(x)) for x in range(5)] # Inline helper function stuff = [(lambda y: [y,x/y])(f(x)) for x in range(5)] # Extra 'for' loop - potentially could be optimized internally stuff = [[y, x/y] for x in range(5) for y in [f(x)]] # Iterating over a genexp stuff = [[y, x/y] for x, y in ((x, f(x)) for x in range(5))] # Expanding the comprehension into a loop stuff = [] for x in range(5): y = f(x) stuff.append([y, x/y]) # Wrapping the loop in a generator function def g(): for x in range(5): y = f(x) yield [y, x/y] stuff = list(g()) # Using a statement-local name stuff = [[(f(x) as y), x/y] for x in range(5)] If calling ``f(x)`` is expensive or has side effects, the clean operation of the list comprehension gets muddled. Using a short-duration name binding retains the simplicity; while the extra ``for`` loop does achieve this, it does so at the cost of dividing the expression visually, putting the named part at the end of the comprehension instead of the beginning. Statement-local name bindings can be used in any context, but should be avoided where regular assignment can be used, just as ``lambda`` should be avoided when ``def`` is an option. As the name's scope extends to the full current statement, even a block statement, this can be used to good effect in the header of an ``if`` or ``while`` statement:: # Current Python, not caring about function return value while input("> ") != "quit": print("You entered a command.") # Current Python, capturing return value - four-line loop header while True: command = input("> "); if command == "quit": break print("You entered:", command) # Proposed alternative to the above while (input("> ") as command) != "quit": print("You entered:", command) # See, for instance, Lib/pydoc.py if (re.search(pat, text) as match): print("Found:", match.group(0)) while (sock.read() as data): print("Received data:", data) Particularly with the ``while`` loop, this can remove the need to have an infinite loop, an assignment, and a condition. It also creates a smooth parallel between a loop which simply uses a function call as its condition, and one which uses that as its condition but also uses the actual value. Performance costs ================= The cost of SLNBs must be kept to a minimum, particularly when they are not used; the normal case MUST NOT be measurably penalized. SLNBs are expected to be uncommon, and using many of them in a single function should definitely be discouraged. Thus the current implementation uses a linked list of SLNB cells, with the absence of such a list being the normal case. This list is used for code compilation only; once a function's bytecode has been baked in, execution of that bytecode has no performance cost compared to regular assignment. Other Python implementations may choose to do things differently, but a zero run-time cost is strongly recommended, as is a minimal compile-time cost in the case where no SLNBs are used. Forbidden special cases ======================= In two situations, the use of SLNBs makes no sense, and could be confusing due to the ``as`` keyword already having a different meaning in the same context. 1. Exception catching:: try: ... except (Exception as e1) as e2: ... The expression ``(Exception as e1)`` has the value ``Exception``, and creates an SLNB ``e1 = Exception``. This is generally useless, and creates the potential confusion in that these two statements do quite different things: except (Exception as e1): except Exception as e2: The latter captures the exception **instance**, while the former captures the ``Exception`` **type** (not the type of the raised exception). 2. Context managers:: lock = threading.Lock() with (lock as l) as m: ... This captures the original Lock object as ``l``, and the result of calling its ``__enter__`` method as ``m``. As with ``except`` statements, this creates a situation in which parenthesizing an expression subtly changes its semantics, with the additional pitfall that this will frequently work (when ``x.__enter__()`` returns x, eg with file objects). Both of these are forbidden; creating SLNBs in the headers of these statements will result in a SyntaxError. Alternative proposals ===================== Proposals broadly similar to this one have come up frequently on python-ideas. Below are a number of alternative syntaxes, some of them specific to comprehensions, which have been rejected in favour of the one given above. 1. ``where``, ``let``, ``given``:: stuff = [(y, x/y) where y = f(x) for x in range(5)] stuff = [(y, x/y) let y = f(x) for x in range(5)] stuff = [(y, x/y) given y = f(x) for x in range(5)] This brings the subexpression to a location in between the 'for' loop and the expression. It introduces an additional language keyword, which creates conflicts. Of the three, ``where`` reads the most cleanly, but also has the greatest potential for conflict (eg SQLAlchemy and numpy have ``where`` methods, as does ``tkinter.dnd.Icon`` in the standard library). 2. ``with NAME = EXPR``:: stuff = [(y, x/y) with y = f(x) for x in range(5)] As above, but reusing the `with` keyword. Doesn't read too badly, and needs no additional language keyword. Is restricted to comprehensions, though, and cannot as easily be transformed into "longhand" for-loop syntax. Has the C problem that an equals sign in an expression can now create a name binding, rather than performing a comparison. Would raise the question of why "with NAME = EXPR:" cannot be used as a statement on its own. 3. ``with EXPR as NAME``:: stuff = [(y, x/y) with f(x) as y for x in range(5)] As per option 2, but using ``as`` rather than an equals sign. Aligns syntactically with other uses of ``as`` for name binding, but a simple transformation to for-loop longhand would create drastically different semantics; the meaning of ``with`` inside a comprehension would be completely different from the meaning as a stand-alone statement, while retaining identical syntax. 4. ``EXPR as NAME`` without parentheses:: stuff = [[f(x) as y, x/y] for x in range(5)] Omitting the parentheses from this PEP's proposed syntax introduces many syntactic ambiguities. Requiring them in all contexts leaves open the option to make them optional in specific situations where the syntax is unambiguous (cf generator expressions as sole parameters in function calls), but there is no plausible way to make them optional everywhere. 5. Adorning statement-local names with a leading dot:: stuff = [[(f(x) as .y), x/.y] for x in range(5)] This has the advantage that leaked usage can be readily detected, removing some forms of syntactic ambiguity. However, this would be the only place in Python where a variable's scope is encoded into its name, making refactoring harder. This syntax is quite viable, and could be promoted to become the current recommendation if its advantages are found to outweigh its cost. 6. Allowing ``(EXPR as NAME)`` to assign to any form of name. This is exactly the same as the promoted proposal, save that the name is bound in the same scope that it would otherwise have. Any expression can assign to any name, just as it would if the ``=`` operator had been used. Such variables would leak out of the statement into the enclosing function, subject to the regular behaviour of comprehensions (since they implicitly create a nested function, the name binding would be restricted to the comprehension itself, just as with the names bound by ``for`` loops). 7. Enhancing ``if`` and ``while`` syntax to permit the capture of their conditions:: if re.search(pat, text) as match: print("Found:", match.group(0)) This works beautifully if and ONLY if the desired condition is based on the truthiness of the captured value. It is thus effective for specific use-cases (regex matches, socket reads that return `''` when done), and completely useless in more complicated cases (eg where the condition is ``f(x) < 0`` and you want to capture the value of ``f(x)``). It also has no benefit to list comprehensions. Discrepancies in the current implementation =========================================== 1. SLNBs are implemented using a special (and mostly-invisible) name mangling. They may sometimes appear in globals() and/or locals() with their simple or mangled names (but buggily and unreliably). They should be suppressed as though they were guinea pigs. 2. The forbidden special cases do not yet raise SyntaxError. References ========== .. [1] Proof of concept / reference implementation (https://github.com/Rosuav/cpython/tree/statement-local-variables) Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End:

18 64