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 be
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 d
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
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
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 dan
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 opportunit
On Wed, Jun 28, 2017 at 9:14 PM, Greg Ewing wrote:
> 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
>> gen
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
dat
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__ are entered.
>
>
> Seems to me
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
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__ are entered.
>
>
> Seems to me
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()
>>>
>>> this is simply *wrong*:
>>>
>>> lock.acquire()
>>> try:
>>>
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
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()
>> finally:
>> lock.release()
>>
>> where
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:
> do_something()
Technically bot
Hi folks,
I normally wouldn't bring something like this up here, except I think
that there is possibility of something to be done--a language
documentation clarification if nothing else, though possibly an actual
code change as well.
I've been having an argument with a colleague over the last cou
16 matches
Mail list logo
