Serhiy Storchaka <storchaka+cpyt...@gmail.com> added the comment:
Right, this is similar to how the JSR/RET pair was used in for calling the
finally block.
It seems the main drawback of duplicating of the finally code is not increasing
the code size (which can be exponential in degenerate cases), but the problem
with determining the boundaries of the finally block.
The main purpose of this issue (getting rid of "pseudo exceptions" in the
interpreter) will be achieved in any case.
This is the first step. In the second step I'm going to get rid of dynamic
PyTryBlock and instructions like SETUP_EXCEPT and POP_BLOCK. I think all
necessary information can be determined at compile time and saved in an
auxiliary structure, similarly as line numbers are saved in the packed
co_lnotab array instead of be set by SET_LINENO instructions. Boundaries of
finally block could be stored in the same structure. This will make try/except/
finally virtually zero-overhead.
In the third step we could generate duplicates of finally blocks. This will be
easier if other changes already applied and tested.
Currently there is other problem with Antoine's PR (I didn't know about them
when made a review). There is a gap between calling the __enter__ method and
the SETUP_FINALLY instruction. If the exception is raised in the gap, the
__exit__ method will be never called. For example:
a = []
with CM() as a[0]: # IndexError
...
I still haven't fixed this problem. Maybe the simplest solution would be to
return the SETUP_WITH instruction which calls __enter__ and creates the finally
block prior to saving the result of __enter__.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue17611>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
