``with from`` statement
Crazy idea. Guido van Rossum mentioned after working on PEP 3156 that context managers cannot use yield from statement inside __enter__ and __exit__ magic methods. Explicit call for entering and leaving context (for locking for example) is not convenient. What do you think about with from f(): do_our_work() ``with from ...` construction calls __enter_from__ generator and iterates via ``yield from`` for that. Returned value is our context manager. The same for __exit_from__ — do``yield from`` for that and stop on StopIteration or exception. -- Thanks, Andrew Svetlov
Nick already proposed "with (yield from ...): ..." Maybe in 3.4 we can tweak the syntax so the paresns are not needed. I am quite glad that we had the foresight (when we designed 'with') to make this possible. On Saturday, December 22, 2012, Andrew Svetlov wrote:
Crazy idea. Guido van Rossum mentioned after working on PEP 3156 that context managers cannot use yield from statement inside __enter__ and __exit__ magic methods. Explicit call for entering and leaving context (for locking for example) is not convenient.
What do you think about
with from f(): do_our_work()
``with from ...` construction calls __enter_from__ generator and iterates via ``yield from`` for that. Returned value is our context manager.
The same for __exit_from__ — do``yield from`` for that and stop on StopIteration or exception.
-- Thanks, Andrew Svetlov _______________________________________________ Python-ideas mailing list Python-ideas@python.org <javascript:;> http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (python.org/~guido)
Yes, Nick's proposal is just awesome. I cannot figure out is __exit__ can be generator which use ``yield from`` also inside? On Sat, Dec 22, 2012 at 7:15 PM, Guido van Rossum <guido@python.org> wrote:
Nick already proposed "with (yield from ...): ..."
Maybe in 3.4 we can tweak the syntax so the paresns are not needed.
I am quite glad that we had the foresight (when we designed 'with') to make this possible.
On Saturday, December 22, 2012, Andrew Svetlov wrote:
Crazy idea. Guido van Rossum mentioned after working on PEP 3156 that context managers cannot use yield from statement inside __enter__ and __exit__ magic methods. Explicit call for entering and leaving context (for locking for example) is not convenient.
What do you think about
with from f(): do_our_work()
``with from ...` construction calls __enter_from__ generator and iterates via ``yield from`` for that. Returned value is our context manager.
The same for __exit_from__ — do``yield from`` for that and stop on StopIteration or exception.
-- Thanks, Andrew Svetlov _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (python.org/~guido)
-- Thanks, Andrew Svetlov
Python syntax looks like use of time machine day by day. I like it! On Sat, Dec 22, 2012 at 7:22 PM, Andrew Svetlov <andrew.svetlov@gmail.com> wrote:
Yes, Nick's proposal is just awesome.
I cannot figure out is __exit__ can be generator which use ``yield from`` also inside?
On Sat, Dec 22, 2012 at 7:15 PM, Guido van Rossum <guido@python.org> wrote:
Nick already proposed "with (yield from ...): ..."
Maybe in 3.4 we can tweak the syntax so the paresns are not needed.
I am quite glad that we had the foresight (when we designed 'with') to make this possible.
On Saturday, December 22, 2012, Andrew Svetlov wrote:
Crazy idea. Guido van Rossum mentioned after working on PEP 3156 that context managers cannot use yield from statement inside __enter__ and __exit__ magic methods. Explicit call for entering and leaving context (for locking for example) is not convenient.
What do you think about
with from f(): do_our_work()
``with from ...` construction calls __enter_from__ generator and iterates via ``yield from`` for that. Returned value is our context manager.
The same for __exit_from__ — do``yield from`` for that and stop on StopIteration or exception.
-- Thanks, Andrew Svetlov _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (python.org/~guido)
-- Thanks, Andrew Svetlov
-- Thanks, Andrew Svetlov
On Sat, Dec 22, 2012 at 10:26 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sat, 22 Dec 2012 19:25:32 +0200 Andrew Svetlov <andrew.svetlov@gmail.com> wrote:
Python syntax looks like use of time machine day by day. I like it!
Not sure I like "with yield from". How do you intend to explain that to an average programmer?
Break it down into pieces. The general form is with <expr>: <block> where <expr> can take many forms, including yield from <expr> we just have to handwave a bit about the priorities, but that's usually okay. People do get x = yield from <expr> It's just that currently somehow you have to surround "yield from <expr>" in an extra pair of parentheses everywhere except on the RHS of an assignment; my other pet peeve in this area is that you must write return (yield from <expr>) (which I end up writing fairly regularly). I assume that if we can make the parens optional for assignment, we can make them optional in other places. -- --Guido van Rossum (python.org/~guido)
On 12/22/2012 2:09 PM, Guido van Rossum wrote:
On Sat, Dec 22, 2012 at 10:26 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sat, 22 Dec 2012 19:25:32 +0200 Andrew Svetlov <andrew.svetlov@gmail.com> wrote:
Python syntax looks like use of time machine day by day. I like it!
Not sure I like "with yield from".
At the moment, that looks a bit dubious to me too. Maybe just because it is new (to me).
How do you intend to explain that to an average programmer?
Break it down into pieces. The general form is
with <expr>: <block>
with <expr> as <expr>: <block> with yield from x() as y: ...
where <expr> can take many forms, including
yield from <expr>
we just have to handwave a bit about the priorities,
Too much dependence on implicit priorities makes the language more baroque and less clear. For instance, I am fine with having to parenthesize generator expressions (except in calls where it would result in doubled parens ((ge))). An explanation need more than a handwave ;-).
but that's usually okay. People do get
x = yield from <expr>
No problem because = cleanly breaks the statement. More a problem is the difference of x coming from a value yielded (or returned?) by the callee instead of a value sent by the caller, as in x = yield y.
It's just that currently somehow you have to surround "yield from <expr>" in an extra pair of parentheses everywhere except on the RHS of an assignment; my other pet peeve in this area is that you must write
return (yield from <expr>)
(which I end up writing fairly regularly).
I can see how that seems like a nuisance. Why that omitting parens bother me less here? Perhaps because return binds the expression to location of the call in the calling expression.
I assume that if we can make the parens optional for assignment, we can make them optional in other places.
If the grammar can be written to do that sufficiently clearly, then it should be explainable to people. -- Terry Jan Reedy
participants (4)
-
Andrew Svetlov -
Antoine Pitrou -
Guido van Rossum -
Terry Reedy