On Mar 13, 2010, at 5:30 AM, Stefan Behnel wrote: > Robert Bradshaw, 13.03.2010 11:36: >> On Mar 13, 2010, at 2:26 AM, Robert Bradshaw wrote: >> >>> 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. >> >> That was a bit rambly. My main points are >> >> - With closures around the corner, and generators soon after, >> we're getting to the point that we need a very specific goal and >> metric for "total Python compatability." >> - With all the other changes going on, I don't think switching >> things over to Py3 semantics by default is a good move right now. >> Better to do it when things are more stable. > > With Py2.7 ahead, which will have most of the features of Py3 except > for > the really backwards incompatible stuff (and potentially some things > that > no-one cares to port), it'll be hard to claim compatibility even > with "Py2.x". > > Then, there's actually three things to consider here: > > a) compatibility with Py2 code (-> when compiling .py files) > b) compatibility with Py3 code (-> .py files + "-3" option or > "cython3") > c) the Cython language (-> .pyx files) > > with the obvious gray area of future imports between a)/c) and b). > > We don't currently care about the file extension, for example. > Should we > generally stop supporting the 'cdef' keyword in .py files?
The only place that the extension currently matters is that with a .py file, signatures and other declarations don't have to match what they are in the .pxd file (the ones from the .pxd file get pulled over). This may result in compile time errors, when renaming a .py file to a .pyx file, which I'm OK with, but we should definitely avoid any behavioral changes due to changing the file extension. The -3 option would be completely orthogonal to the file extension, and could be used with both .py and .pyx files. > I think we need to do that if we really want to introduce a well > defined > notion of "language level compatibility". What I want is that Cython is a superset of Python. In particular, for widespread use it should be safe (barring bugs) to just compile a .py file and run it. I don't think our "language level compatibility" needs to be more granular than Py2 (meaning specifically 2.6, or maybe 2.7) and Py3 (meaning 3.1?), at least not right now (there are bigger fish to fry). - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
