Re: [Python-Dev] Inconsistency between PEP492, documentation and behaviour of "async with"
> > Can someone please clarify the exact behaviour of "async with"? > > "async with" is expected to behave essentially the same way that > normal "with" does as far as return, break, and continue are concerned > (i.e. calling __aexit__ without an exception set, so it's more like > try/finally than it is try/else). > > Would you mind filing a documentation bug for that? We clearly missed > that the semantics described in the new documentation didn't actually > match the original with statement semantics (even though matching > those semantics is the intended behaviour). Ok, bug filed at: http://bugs.python.org/issue30707 ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistency between PEP492, documentation and behaviour of "async with"
On 19 June 2017 at 16:35, Damien George wrote:
> Hi all,
>
> Regarding the behaviour of the "async with" statement: it seems that the
> description of it in PEP492, and the language documentation, do not match
> the behaviour of CPython (v3.6.1).
>
> The PEP and the docs here:
> https://www.python.org/dev/peps/pep-0492/#asynchronous-context-managers-and-async-with
> https://docs.python.org/3/reference/compound_stmts.html#async-with
> say that "async with" is equivalent to a particular use of try/except/else.
>
> But the implementation seems more like a try/except/finally, because the
> __aexit__ is always executed, even if a return statement is in the try block
> ("else" won't be executed if there's a "return" in the "try"). Also, as per
> normal "with", the implementation is a bit more complex than
> try/except/finally because you don't want to execute the __aexit__ method
> twice if there is an exception in the try.
>
> Can someone please clarify the exact behaviour of "async with"?
"async with" is expected to behave essentially the same way that
normal "with" does as far as return, break, and continue are concerned
(i.e. calling __aexit__ without an exception set, so it's more like
try/finally than it is try/else).
Would you mind filing a documentation bug for that? We clearly missed
that the semantics described in the new documentation didn't actually
match the original with statement semantics (even though matching
those semantics is the intended behaviour).
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Inconsistency between PEP492, documentation and behaviour of "async with"
Hi all,
Regarding the behaviour of the "async with" statement: it seems that the
description of it in PEP492, and the language documentation, do not match
the behaviour of CPython (v3.6.1).
The PEP and the docs here:
https://www.python.org/dev/peps/pep-0492/#asynchronous-context-managers-and-async-with
https://docs.python.org/3/reference/compound_stmts.html#async-with
say that "async with" is equivalent to a particular use of try/except/else.
But the implementation seems more like a try/except/finally, because the
__aexit__ is always executed, even if a return statement is in the try
block ("else" won't be executed if there's a "return" in the "try"). Also,
as per normal "with", the implementation is a bit more complex than
try/except/finally because you don't want to execute the __aexit__ method
twice if there is an exception in the try.
Can someone please clarify the exact behaviour of "async with"?
Background: in implementing "async with" in MicroPython, we went by the
PEP/docs, and now our behaviour doesn't match that of CPython.
Cheers,
Damien.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
