On 03/17/2011 12:24 AM, Greg Ewing wrote:
Stefan Behnel wrote:
I'm not sure if this is a good idea. "nogil" blocks don't have a way
to handle exceptions, so simply jumping out of them because an inner
'with gil' block raised an exception can have unexpected side effects.
Seems to me that the
On 03/17/2011 08:38 AM, Dag Sverre Seljebotn wrote:
On 03/17/2011 12:24 AM, Greg Ewing wrote:
Stefan Behnel wrote:
I'm not sure if this is a good idea. "nogil" blocks don't have a way
to handle exceptions, so simply jumping out of them because an inner
'with gil' block raised an exception can
Dag Sverre Seljebotn, 17.03.2011 08:38:
On 03/17/2011 12:24 AM, Greg Ewing wrote:
Stefan Behnel wrote:
I'm not sure if this is a good idea. "nogil" blocks don't have a way to
handle exceptions, so simply jumping out of them because an inner 'with
gil' block raised an exception can have unexpec
On 03/17/2011 09:27 AM, Stefan Behnel wrote:
Dag Sverre Seljebotn, 17.03.2011 08:38:
On 03/17/2011 12:24 AM, Greg Ewing wrote:
Stefan Behnel wrote:
I'm not sure if this is a good idea. "nogil" blocks don't have a
way to
handle exceptions, so simply jumping out of them because an inner
'with
On 17 March 2011 10:08, Dag Sverre Seljebotn wrote:
> On 03/17/2011 09:27 AM, Stefan Behnel wrote:
>>
>> Dag Sverre Seljebotn, 17.03.2011 08:38:
>>>
>>> On 03/17/2011 12:24 AM, Greg Ewing wrote:
Stefan Behnel wrote:
> I'm not sure if this is a good idea. "nogil" blocks don't hav
On 17 March 2011 09:27, Stefan Behnel wrote:
> Dag Sverre Seljebotn, 17.03.2011 08:38:
>>
>> On 03/17/2011 12:24 AM, Greg Ewing wrote:
>>>
>>> Stefan Behnel wrote:
>>>
I'm not sure if this is a good idea. "nogil" blocks don't have a way to
handle exceptions, so simply jumping out of them
On 03/17/2011 11:16 AM, mark florisson wrote:
On 17 March 2011 10:08, Dag Sverre Seljebotn wrote:
How about this compromise: We balk on the code you wrote with:
Error line 345: Exceptions propagating from "with gil" block cannot be
propagated out of function, please insert try/except and hand
On 17 March 2011 11:35, Dag Sverre Seljebotn wrote:
> On 03/17/2011 11:16 AM, mark florisson wrote:
>>
>> On 17 March 2011 10:08, Dag Sverre Seljebotn
>> wrote:
>>>
>>> How about this compromise: We balk on the code you wrote with:
>>>
>>> Error line 345: Exceptions propagating from "with gil" bl
On 3/16/11 11:05 PM, Robert Bradshaw wrote:
On Wed, Mar 16, 2011 at 7:53 AM, Stefan Behnel wrote:
I'm actually leaning towards not guaranteeing the order of execution if C
doesn't do it either. If this is really required, it's easy to work around
for users, but it's severely hard to fix for Cyt
On Thu, Mar 17, 2011 at 6:15 AM, Jason Grout
wrote:
> On 3/16/11 11:05 PM, Robert Bradshaw wrote:
>>
>> On Wed, Mar 16, 2011 at 7:53 AM, Stefan Behnel
>> wrote:
>>>
>>> I'm actually leaning towards not guaranteeing the order of execution if C
>>> doesn't do it either. If this is really required,
2011/3/17 Robert Bradshaw :
> On Thu, Mar 17, 2011 at 6:15 AM, Jason Grout
> wrote:
>> On 3/16/11 11:05 PM, Robert Bradshaw wrote:
>>>
>>> On Wed, Mar 16, 2011 at 7:53 AM, Stefan Behnel
>>> wrote:
I'm actually leaning towards not guaranteeing the order of execution if C
doesn't do
On Thu, Mar 17, 2011 at 1:48 PM, Vitja Makarov wrote:
> 2011/3/17 Robert Bradshaw :
>> On Thu, Mar 17, 2011 at 6:15 AM, Jason Grout
>> wrote:
>>> On 3/16/11 11:05 PM, Robert Bradshaw wrote:
On Wed, Mar 16, 2011 at 7:53 AM, Stefan Behnel
wrote:
>
> I'm actually leaning towa
Robert Bradshaw, 17.03.2011 05:05:
On Wed, Mar 16, 2011 at 7:53 AM, Stefan Behnel wrote:
I'm actually leaning towards not guaranteeing the order of execution if C
doesn't do it either. If this is really required, it's easy to work around
for users, but it's severely hard to fix for Cython in all
On Thu, Mar 17, 2011 at 2:25 PM, Stefan Behnel wrote:
> Robert Bradshaw, 17.03.2011 05:05:
>>
>> On Wed, Mar 16, 2011 at 7:53 AM, Stefan Behnel wrote:
>>>
>>> I'm actually leaning towards not guaranteeing the order of execution if C
>>> doesn't do it either. If this is really required, it's easy t
Robert Bradshaw, 17.03.2011 22:26:
On Thu, Mar 17, 2011 at 2:25 PM, Stefan Behnel wrote:
Robert Bradshaw, 17.03.2011 05:05:
On Wed, Mar 16, 2011 at 7:53 AM, Stefan Behnel wrote:
I'm actually leaning towards not guaranteeing the order of execution if C
doesn't do it either. If this is really
Dag Sverre Seljebotn wrote:
def f():
with nogil:
for ...:
A
if something_exceptional:
with gil:
raise Exception(...)
B
C
If that's to be supported, the following really ought to be
supported as well:
On 18 March 2011 00:32, Greg Ewing wrote:
> Dag Sverre Seljebotn wrote:
>
>> def f():
>> with nogil:
>> for ...:
>> A
>> if something_exceptional:
>> with gil:
>> raise Exception(...)
>> B
>> C
>
> If that's to be
On 16 March 2011 20:16, mark florisson wrote:
Could someone review the patch (which is attached)? Maybe check if I
haven't missed any side cases and such?
>>>
>>> From a first look, the test file you added seems far too short. I would
>>> expect that this feature requires a lot more test
mark florisson wrote:
I think we could support it without having to acquire
the GIL in the finally clause.
That was the intention -- the code in the finally clause would
be subject to the same nogil restrictions as the rest of
the nogil block.
My point is that as long as you're allowing except
Greg Ewing, 18.03.2011 01:18:
mark florisson wrote:
I think we could support it without having to acquire
the GIL in the finally clause.
That was the intention -- the code in the finally clause would
be subject to the same nogil restrictions as the rest of
the nogil block.
My point is that as
20 matches
Mail list logo
