> 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-requ...@python.org>: > Send Python-ideas mailing list submissions to > python-ideas@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-requ...@python.org > > You can reach the person managing the list at > python-ideas-ow...@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 <ros...@gmail.com> > To: python-ideas <python-ideas@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.mo...@gmail.com> wrote: > > On 11 April 2018 at 22:28, Chris Angelico <ros...@gmail.com> wrote: > >> On Thu, Apr 12, 2018 at 1:22 AM, Nick Coghlan <ncogh...@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 <ros...@gmail.com> > To: python-ideas <python-ideas@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 <kirillbalu...@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 <ncogh...@gmail.com> > To: Chris Angelico <ros...@gmail.com> > Cc: python-ideas <python-ideas@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 <ros...@gmail.com> wrote: > > On Thu, Apr 12, 2018 at 1:22 AM, Nick Coghlan <ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia > > > > ---------- 已转发邮件 ---------- > From: Jacco van Dorp <j.van.d...@deonet.nl> > To: python-ideas <python-ideas@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 <ncogh...@gmail.com>: > > On 12 April 2018 at 22:22, Jacco van Dorp <j.van.d...@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 <ros...@gmail.com> > To: python-ideas <python-ideas@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.d...@deonet.nl> > wrote: > > 2018-04-12 15:02 GMT+02:00 Nick Coghlan <ncogh...@gmail.com>: > >> On 12 April 2018 at 22:22, Jacco van Dorp <j.van.d...@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@python.org > https://mail.python.org/mailman/listinfo/python-ideas > >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/