On 03/18/2011 11:10 AM, Stefan Behnel wrote:
mark florisson, 18.03.2011 10:52:
On 18 March 2011 07:07, Stefan Behnel wrote:
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 long as you're allowing exceptions to be
tunnelled through nogil blocks, they should respect any finally
clauses that they pass through on the way.
+1
Ok, I will give it a go and try to allow it when they surround with
gil blocks. I would however like to reiterate that it is a
special-case, inconsistent with previous behaviour, and basically
extends the language and won't work for functions that are called and
declared 'with gil'. But it is convenient, so I can't help but like it
at the same time :]
I'm not sure I understand why you think it's so bad, and why it would
be inconsistent with previous behaviour.
The only real problem I see is that you could do things like this:
with nogil:
try:
with gil: raise ...
finally:
with gil: raise ...
i.e. you could loose the original exception. Even worse:
with nogil:
try:
with gil: raise ...
finally:
with gil:
try: raise
except: pass
Here, it must be made sure that the original exception still gets
raised properly at the end. That's a problem in Py2, where exceptions
are badly scoped, i.e. Python code that runs in the interpreter could
fail to reset the original exception after catching another one. But I
guess these things are up to the "with gil" block/function, rather
than the above "finally" clause.
Actually, I think I still find it more convenient to not provide *any*
special exception paths through nogil code, i.e. to not let exceptions
in "with gil" blocks exit from outer "nogil" blocks. That would avoid
all of the semantic difficulties above.
Well, of course not supporting something is easier. But is it user
friendly? Relying on boolean flags to signal errors states is a real
pain when one is used to using exceptions.
Dag Sverre
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
