Re: [Python-Dev] 'continue'/'break'/'return' inside 'finally' clause
Serhiy Storchaka <storchaka@gmail.com> wrote:
Currently 'break' and 'return' are never used inside 'finally' clause in the stdlib.
See the _recv_bytes() function: Lib/multiprocessing/connection.py: 316
I would want to see a third-party code that uses them.
These are the only ones I found so far: ./gevent/src/gevent/libev/corecffi.py: 147 ./gevent/src/gevent/threadpool.py: 226 I have an AST walker script that finds them. Regards, Neil
Generally I think programming language implementers don't get to decide how the language works. You just have to implement it as specified, inconvenient as that might be. However, from a languge design prespective, I think there is a good argument that this is a corner of the language we should consider changing. First, I analyzed over one million lines of Python code with my AST walker and only found this construct being used in four different places. It seems to be extremely rare. Second, the existance of a pylint warning for it suggests that it is confusing. I did a little more searching using the pylint warning and found these pages: https://stackoverflow.com/questions/35505624/break-statement-in-finally-bloc... http://thegreyblog.blogspot.ca/2011/02/do-not-return-in-finally-block-return... So, given the above and that the implementation (both compiler and bytecode evaluator) is pretty complicated, I vote that we should disallow it. Regards, Neil
02.01.18 22:31, Neil Schemenauer пише:
Serhiy Storchaka <storchaka@gmail.com> wrote:
Currently 'break' and 'return' are never used inside 'finally' clause in the stdlib.
See the _recv_bytes() function:
Lib/multiprocessing/connection.py: 316
Thank you Neil! I missed this case because ran only fast tests, without enabling network tests.
I would want to see a third-party code that uses them.
These are the only ones I found so far:
../gevent/src/gevent/libev/corecffi.py: 147
I haven't found 'finally' clauses in https://github.com/gevent/gevent/blob/master/src/gevent/libev/corecffi.py. Perhaps this code was changed in recent versions. In any case we now know that this combination is occurred (but very rarely) in the wild.
On 2018-01-03, Serhiy Storchaka wrote:
I haven't found 'finally' clauses in https://github.com/gevent/gevent/blob/master/src/gevent/libev/corecffi.py. Perhaps this code was changed in recent versions.
Yes, I was looking at was git revision bcf4f65e. I reran my AST checker and found this: ./src/gevent/_ffi/loop.py: 181: return inside finally
In any case we now know that this combination is occurred (but very rarely) in the wild.
Looks like it. If we do want to seriously consider changing the grammar, I will download more packages of PyPI and check them. BTW, ./src/gevent/threadpool.py doesn't compile with 3.7 because it uses 'async' as a variable name. So either they didn't notice the deprecation warnings or they didn't care to update their code. Regards, Neil
I'm sorry, I don't think more research can convince me either way. I want all three of return/break/continue to work inside finally clauses, despite there being few use cases. On Wed, Jan 3, 2018 at 2:30 PM, Neil Schemenauer <nas-python@arctrix.com> wrote:
I haven't found 'finally' clauses in https://github.com/gevent/gevent/blob/master/src/gevent/
On 2018-01-03, Serhiy Storchaka wrote: libev/corecffi.py.
Perhaps this code was changed in recent versions.
Yes, I was looking at was git revision bcf4f65e. I reran my AST checker and found this:
./src/gevent/_ffi/loop.py: 181: return inside finally
In any case we now know that this combination is occurred (but very rarely) in the wild.
Looks like it. If we do want to seriously consider changing the grammar, I will download more packages of PyPI and check them.
BTW, ./src/gevent/threadpool.py doesn't compile with 3.7 because it uses 'async' as a variable name. So either they didn't notice the deprecation warnings or they didn't care to update their code.
Regards,
Neil _______________________________________________ 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/ guido%40python.org
-- --Guido van Rossum (python.org/~guido)
On 2018-01-03, Guido van Rossum wrote:
I'm sorry, I don't think more research can convince me either way. I want all three of return/break/continue to work inside finally clauses, despite there being few use cases.
That's fine. The history of 'continue' inside 'finally' is interesting. The restriction dates back to at least when Jeremy committed the AST-based compiler (I have fond memories of hacking on it with Armin Rigo and others at a Python core sprint). Going further back, I looked at 1.5.2 and there is the comment in compile.c: TO DO: ... XXX Allow 'continue' inside try-finally So if we allow 'continue' we will be knocking off a nearly 20 year old todo item. ;-) For giggles, I unpacked a Python 0.9.1 tarball. The source code is all under 'src' in that version. There doesn't seem to be a restriction on 'continue' but only because the grammar doesn't include it! Without doing more research, I think the restriction could be as old as the 'continue' keyword. BTW, the bytecode structure for try/except shown in the compile.c comments is very simlar to what is currently generated. It is quite remarkable how well your initial design and implementation have stood the test of time. Thank you for making it open source. Regards, Neil
We should interview you for the paper we may be writing for HOPL. On Wed, Jan 3, 2018 at 6:05 PM, Neil Schemenauer <nas-python@arctrix.com> wrote:
On 2018-01-03, Guido van Rossum wrote:
I'm sorry, I don't think more research can convince me either way. I want all three of return/break/continue to work inside finally clauses, despite there being few use cases.
That's fine. The history of 'continue' inside 'finally' is interesting. The restriction dates back to at least when Jeremy committed the AST-based compiler (I have fond memories of hacking on it with Armin Rigo and others at a Python core sprint). Going further back, I looked at 1.5.2 and there is the comment in compile.c:
TO DO: ... XXX Allow 'continue' inside try-finally
So if we allow 'continue' we will be knocking off a nearly 20 year old todo item. ;-)
For giggles, I unpacked a Python 0.9.1 tarball. The source code is all under 'src' in that version. There doesn't seem to be a restriction on 'continue' but only because the grammar doesn't include it! Without doing more research, I think the restriction could be as old as the 'continue' keyword.
BTW, the bytecode structure for try/except shown in the compile.c comments is very simlar to what is currently generated. It is quite remarkable how well your initial design and implementation have stood the test of time. Thank you for making it open source.
Regards,
Neil
-- --Guido van Rossum (python.org/~guido)
On 2018-01-04, Guido van Rossum wrote:
We should interview you for the paper we may be writing for HOPL.
History of Programming Languages? I did some more digging this afternoon, trying to find source code between versions 1.0.1 and 0.9.1. No luck though. It looks like 0.9.1 might have been the last one you uploaded to alt.sources. Later 0.9.X releases were uploaded to ftp.cwi.nl and wuarchive.wustle.edu. No one seems to have an archive of those. I think all my old PCs have been sent to the scrapyard. I might have some old hard disk images somewhere. Maybe on a writable DVD or CDR. Probably unreadable at this point. I don't know exactly which version of Python I first downloaded. No earlier than the fall of 1992 and maybe 1993 but it could have been pre-1.0. I do recall running a DOS port at some point. Here is the announcement of 0.9.4alpha: http://legacy.python.org/search/hypermail/python-1992/0270.html The Misc/HISTORY file has quite a lot of details. It shows that 'continue' was added in 0.9.2. Back on topic, it looks like allowing 'continue' will be trival once Serhiy's unwind stack PR lands. Just a few lines of code and I think everything works. If Mark implements his alternative "wordcode for finally blocks gets copied" thing, it will make things more complicated but not much more so than handling 'break' and 'return'. So, those three should probably be all allowed or all forbidden. Regards, Neil
participants (3)
-
Guido van Rossum -
Neil Schemenauer -
Serhiy Storchaka