> 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@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-request@python.org

You can reach the person managing the list at
        python-ideas-owner@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@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.moore@gmail.com> wrote:
> On 11 April 2018 at 22:28, Chris Angelico <rosuav@gmail.com> wrote:
>> On Thu, Apr 12, 2018 at 1:22 AM, Nick Coghlan <ncoghlan@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@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 <kirillbalunov@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@gmail.com>
To: Chris Angelico <rosuav@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 <rosuav@gmail.com> wrote:
> On Thu, Apr 12, 2018 at 1:22 AM, Nick Coghlan <ncoghlan@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@gmail.com   |   Brisbane, Australia



---------- 已转发邮件 ----------
From: Jacco van Dorp <j.van.dorp@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 <ncoghlan@gmail.com>:
> On 12 April 2018 at 22:22, Jacco van Dorp <j.van.dorp@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@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.dorp@deonet.nl> wrote:
> 2018-04-12 15:02 GMT+02:00 Nick Coghlan <ncoghlan@gmail.com>:
>> On 12 April 2018 at 22:22, Jacco van Dorp <j.van.dorp@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