``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:
-- --Guido van Rossum (python.org/~guido)
On Sat, Dec 22, 2012 at 10:26 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
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:
At the moment, that looks a bit dubious to me too. Maybe just because it is new (to me).
with <expr> as <expr>: <block> with yield from x() as y: ...
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.
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
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:
-- --Guido van Rossum (python.org/~guido)
On Sat, Dec 22, 2012 at 10:26 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:
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:
At the moment, that looks a bit dubious to me too. Maybe just because it is new (to me).
with <expr> as <expr>: <block> with yield from x() as y: ...
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.
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