On Fri, Sep 21, 2018 at 12:58 AM Chris Angelico <ros...@gmail.com> wrote:
>
> On Fri, Sep 21, 2018 at 8:52 AM Kyle Lahnakoski <klahnako...@mozilla.com>
> wrote:
> > Since the java.lang.Thread.stop() "debacle", it has been obvious that
> > stopping code to run other code has been dangerous. KeyboardInterrupt
> > (any interrupt really) is dangerous. Now, we can probably code a
> > solution, but how about we remove the danger:
> >
> > I suggest we remove interrupts from Python, and make them act more like
> > java.lang.Thread.interrupt(); setting a thread local bit to indicate an
> > interrupt has occurred. Then we can write explicit code to check for
> > that bit, and raise an exception in a safe place if we wish. This can
> > be done with Python code, or convenient places in Python's C source
> > itself. I imagine it would be easier to whitelist where interrupts can
> > raise exceptions, rather than blacklisting where they should not.
>
> The time machine strikes again!
>
> https://docs.python.org/3/c-api/exceptions.html#signal-handling
Although my original post did not explicitly mention
PyErr_CheckSignals() and friends, it had already taken that into
account and it is not a silver bullet, at least w.r.t. the exact issue
I raised, which had to do with the behavior of context managers versus
the
setup()
try:
do_thing()
finally:
cleanup()
pattern, and the question of how signals are handled between Python
interpreter opcodes. There is a still-open bug on the issue tracker
discussing the exact issue in greater details:
https://bugs.python.org/issue29988
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
