Hi, Robert Bradshaw wrote: > On Nov 5, 2008, at 11:18 AM, Stefan Behnel wrote: >> Robert Bradshaw wrote: >>> I think the most immediate official milestone is being able to >>> compile 100% of Cython code. This is the target for 1.0. >> Did you really mean Cython here or Python? I think 100% Python is >> somewhat >> hard to prove. I would expect that we are pretty close to compiling >> Py2.4 >> code, and a bit further from compiling 2.5 code (which mainly includes >> generator expressions). Not sure about 2.6, which was a heavily >> moving target >> last time I checked. > > Sorry, I meant Python here. I'd say the goal is at a minimum to run > the entire Python regression suite for 2.x, probably 2.4 or 2.5.
Then runtests.py --sys-pyregr is your friend. :) Note that this requires the Python test suite to be installed, which isn't the case in a normal Python install (at least on most Linux distros). The best is to build your own clean Python somewhere apart and use that. If compiling Python is our first goal, I suggest that people get "sys-pyregr" running on a Python 2.5 installation and fix tests. When a test fails unexpectedly, I'd also suggest to check it again with Python 2.6, just to be sure it didn't change behaviour. >> If you meant Cython, this requires a stable definition of what the >> Cython language actually is. > > Yeah, I'd certainly like to eventually move to a more stable (and > precise) definition than "whatever the compiler accepts at the > moment" :). Yep, that's the state of the art. :) IMHO, the definition is something in the lines of Python 2.5 - some unsupportable features + some well defined C features + some additional features: buffer syntax, pure Python syntax, ... Some of that is in the Wiki already. > What is the timeline for Py2.7? I don't think there is one yet, but I'd expect a beta by next summer, given that 2.6 final is out, the developers are focussing on Py3.0 now, and 2.7/3.1 are expected to be cleanup releases. > Also, if we migrate our source to > Py3, will that exclude running it under Py2? Will we have to maintain > two separate codebases? I still hope that the 2to3 tool (or maybe a future 3to2 tool, as often discussed) will help us here once we get the code clean enough. Plex is a problem, for example, but not a major one either. I think the test suite is good enough by now to give these things another try. >>> One thing that is not clear is >>> if a (sufficiently advanced?) user would be able to use the newer >>> Cython with an older version of Python (say, if some projects/modules >>> he needed weren't ported yet.) >> I'm not sure where you see the problem here. A user wouldn't >> replace the core >> Cython (i.e. everything else would keep working), but import a >> separate Cython >> install instead. > > If it could hook in an "hijack" the builtin one, especially if > there's tighter integration of the latter, then that would be very cool. PyXML did that with the stock Python XML support - although not very beautifully. So, yes, there are ways to do these things. We will just have to find one that users can live with. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
