Robert Bradshaw, 13.03.2010 09:25:
>> >>> e = None
>> >>> try: raise ValueError
>> ... except ValueError as e: pass
>> ...
>> >>> e
>
> In the face of differing behavior Cython follows Python 2.x scoping
> conventions, e.g. the same issue arises for list comprehensions.

It's actually very easy for the exception case. You could have Py2 scoping for

     except ValueError, e:

and Py3 scoping for

     except ValueError as e:

Although I would prefer having the same (Py3) rules for both.

I think Cython should generally try to follow Py3 also for the corner case 
of list comps. The use cases where the behaviour differs (i.e. when the 
internal names are used outside of the comp scope) are rarely used, 
generally known to be broken by Py3 anyway, and easy to fix (and clean up) 
by not using a list-comp in the first place. So I propose that Cython code 
that relies on them now should be considered relying on undefined behaviour 
and allowed to be broken in a future Cython version.

What do you think?


 > In any case, it's bad that the empty except block behaves differently
 > than the non-empty one.

Sure.


> The problem is this comment:
>
>>> # most simple case: no exception variable, empty body (pass)
>
> which is *not* what is being tested.

Agreed.


> Anyone opposed to
>
> diff -r 587136bd1d75 Cython/Compiler/Nodes.py
> --- a/Cython/Compiler/Nodes.py        Sat Mar 13 08:24:13 2010 +0100
> +++ b/Cython/Compiler/Nodes.py        Sat Mar 13 00:24:33 2010 -0800
> @@ -4497,7 +4497,8 @@
>            else:
>                code.putln("/*except:*/ {")
>
> -        if not getattr(self.body, 'stats', True):
> +        if not getattr(self.body, 'stats', True) and
> +                self.excinfo_target is None and self.target is None):
>                # most simple case: no exception variable, empty body
> (pass)
>                # =>  reset the exception state, done
>                code.putln("PyErr_Restore(0,0,0);")

Fine with me. It doesn't make much sense to assign the exception to a 
variable on an empty except block, unless you explicitly want it to stay 
available after the block (thus depending on Py2 semantics).

Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to