On Nov 5, 2008, at 11:18 AM, Stefan Behnel wrote: > Hi, > > 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. > 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" :). >> there are several other things (e.g. the constantly improving buffer >> support) that are not part of this goal but extremely valuable. I >> imagine once we hit that target things will still be in flux > > I think that's somewhat orthogonal. I can imagine a stable language > core with > optional, advanced features. Both can well have different levels of > maturity, > both can mature in different release cycles - the more stable ones > in the > Python stdlib, and the more experimental or younger ones in > independent Cython > releases. It *is* orthogonal, my point was that I think pursuing this stuff is at least as important as the other goals we're talking about here. >> >> that inclusion into the Python stdlib will be premature at that >> point, but worth moving towards. > > I'm more thinking in terms of stabilising the core language and major > features. If we shift a bit of our current focus towards that goal, > a core > Cython release could even go into Py2.7. (Note that inclusion in > Py3.1 would > require migrating the source code to Py3 first, which is still a > bit of > additional work, but definitely worth it). What is the timeline for Py2.7? Also, if we migrate our source to Py3, will that exclude running it under Py2? Will we have to maintain two separate codebases? > >> 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. > Just an idea: I would imagine that we will (finally) have to lower- > case the > package/module names when we move into the stdlib, but we may keep > (at least) > the upper-case Cython package for the stand-alone release. We could > then > install with a lower-case package (or both) under Python 2.3-2.6, > and with an > upper-case package name on Python versions that already have a > packaged Cython. The lower/upper case thing could be confusing to some, but might be worth it. > >> There is also the long term question >> of the parser which is very redundant with the one shipped with >> Python. (Would we try to migrate over to Python's ASTs? Could that be >> done without loosing the old-style cdef syntax?) > > That's really a long-term question and something that we should > discuss with > the CPython developers. If we become an official part of CPython, I > imagine > that there will be ways to hook into the existing parser /somewow/. Yep. "cdef int foo(int y)" is just so convenient to write. It'd be nice to not have to duplicate 90% of the parser code, but I'm sure we'll be able to cross that bridge when we come to it. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
