Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

2018-09-24 Thread Chris Angelico
On Tue, Sep 25, 2018 at 1:10 AM Erik Bray wrote: > > On Fri, Sep 21, 2018 at 12:58 AM Chris Angelico wrote: > > > > On Fri, Sep 21, 2018 at 8:52 AM Kyle Lahnakoski > > wrote: > > > Since the java.lang.Thread.stop() "debacle", it has been obvious that > > > stopping code to run other code has

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

2018-09-24 Thread Erik Bray
On Fri, Sep 21, 2018 at 12:58 AM Chris Angelico wrote: > > On Fri, Sep 21, 2018 at 8:52 AM Kyle Lahnakoski > 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

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

2018-09-20 Thread Michael Selik
On Thu, Sep 20, 2018, 3:52 PM Kyle Lahnakoski wrote: > KeyboardInterrupt (any interrupt really) is dangerous. Now, we can > probably code a solution, but how about we remove the danger > The other day I accidentally fork-bombed myself with Python os.fork in an infinite loop. Whoops. It seems to

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

2018-09-20 Thread Chris Angelico
On Fri, Sep 21, 2018 at 8:52 AM Kyle Lahnakoski 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

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

2018-09-20 Thread Kyle Lahnakoski
On 2017-06-28 07:40, Erik Bray wrote: > Hi folks, 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

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

2017-06-29 Thread Greg Ewing
Nathaniel Smith wrote: A magic (implemented in C) decorator like @async_signals_masked I think would be the simplest way to do this extension. I don't have a good feeling about that approach. While implementing the decorator in C might be good enough in CPython to ensure no window of

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

2017-06-28 Thread Greg Ewing
Nathaniel Smith wrote: So what should this async_signals_masked state do when we yield out from under it? If it's a thread-local, then the masking state will "leak" into other async function callstacks (or similar for regular generators), which is pretty bad. But it can't be just frame-local

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

2017-06-28 Thread Nathaniel Smith
On Wed, Jun 28, 2017 at 6:19 AM, Greg Ewing wrote: > Erik Bray wrote: >> >> At this point a potentially >> waiting SIGINT is handled, resulting in KeyboardInterrupt being raised >> while inside the with statement's suite, and finally block, and hence >> Lock.__exit__

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

2017-06-28 Thread Greg Ewing
Erik Bray wrote: My question would be to make that a language-level requirement of the context manager protocol, or just something CPython does... I think it should be a language-level requirement, otherwise it's not much use. Note that it's different from some existing CPython-only behaviour

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

2017-06-28 Thread Erik Bray
On Wed, Jun 28, 2017 at 3:19 PM, Greg Ewing wrote: > Erik Bray wrote: >> >> At this point a potentially >> waiting SIGINT is handled, resulting in KeyboardInterrupt being raised >> while inside the with statement's suite, and finally block, and hence >> Lock.__exit__

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

2017-06-28 Thread Erik Bray
On Wed, Jun 28, 2017 at 3:09 PM, Erik Bray wrote: > On Wed, Jun 28, 2017 at 2:26 PM, Nick Coghlan wrote: >> On 28 June 2017 at 21:40, Erik Bray wrote: >>> My colleague's contention is that given >>> >>> lock = threading.Lock()

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

2017-06-28 Thread Greg Ewing
Erik Bray wrote: At this point a potentially waiting SIGINT is handled, resulting in KeyboardInterrupt being raised while inside the with statement's suite, and finally block, and hence Lock.__exit__ are entered. Seems to me this is the behaviour you *want* in this case, otherwise the lock can

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

2017-06-28 Thread Erik Bray
On Wed, Jun 28, 2017 at 2:26 PM, Nick Coghlan wrote: > On 28 June 2017 at 21:40, Erik Bray wrote: >> My colleague's contention is that given >> >> lock = threading.Lock() >> >> this is simply *wrong*: >> >> lock.acquire() >> try: >> do_something()

Re: [Python-ideas] Asynchronous exception handling around with/try statement borders

2017-06-28 Thread Nick Coghlan
On 28 June 2017 at 21:40, Erik Bray wrote: > My colleague's contention is that given > > lock = threading.Lock() > > this is simply *wrong*: > > lock.acquire() > try: > do_something() > finally: > lock.release() > > whereas this is okay: > > with lock: >