On Mar 13, 2010, at 1:25 AM, Stefan Behnel wrote: > 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.
This may be a bit confusing for some, but I could live with that. > 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? The stated goal for Cython 1.0 is to compile and (correctly) run any Python code. In practice, this means I should be able to take any piece of Python code and safely compile and run it without any changes (perhaps with a --pedantic flag if some corner cases are considered to expensive to not be worth handling, though none come to mind at the moment). This can't be the case if the Cython language (which is also too ill-defined) is a mixture of Py2 and Py3 semantics (where the syntaxes overlap). Given that the we currently have Py2 semantics for nearly everything, and have the __future__ directives, until we hit 1.0 at least it makes the most sense to stick with that. (It's also inline with the "easiest way to port code to 3.x :)). Thus the refined goal would be be supporting any Python 2.6 code compiled against Python 2.6 to have exactly the same behavior (modulo obvious differences like introspection) as if it were interpreted. I think it would be a good idea to have flag/directive for compiling code with Python 3 semantics, and perhaps eventually switch over to that by default (or in a 3.x context?) after throwing in some warning/ deprecation code in there, but the time to make such backwards incompatible changes is not now. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
