Hi Dag, Dag Sverre Seljebotn wrote: > As many of you know me and Kurt attended SciPy 09. Four Cython-related > events were held: > > - An introductory tutorial to Cython (by me) > - A talk about Cython for numerics (by me again) > - A talk on Fwrap (by Kurt) > - A Cython BoF > > You can find links to slides and videos for the three first on > http://conference.scipy.org. > > An intensive week like that makes me reflect on what Cython is good > about, lacking, etc. etc. > > First of all, there seems to be quite a lot of interest in Cython, many > thinks it is excellent, and many thanked me personally for our efforts. > > One thing that's also very interesting to me personally is that there's > some talk of porting parts of NumPy over to Cython for easier Python 3 > support.
This sounds like Cython is still heavily growing in interest, which is a really good thing. Thanks for spreading the word so loudly. > Beyond that, I've got a nice list of topics for further improvement. For > instance one thing that is very possible to fix was a real dealbreaker > that some complained about, and in one case stopped somebody from > recommending it to co-workers. It's always nice to get the "outside" > perspective that I get when I present Cython to lots of people. Well, the list of requested features has been growing pretty long by now, as has the list of things that need fixing. The Cython project is definitely not lacking ideas. > It seems to me that many has the impression that > > a) Cython is complicated technology which takes much work > b) A lot of effort is put into steadily improving it > > BUT, I feel the reality is that > > a) Core developers can implement new features or fix bugs rather quickly > b) Relatively little time is spent in total on Cython, compared to some > other projects I totally second this. While the amount of developer time that is currently available from the core developers is strictly limited by a variety of factors, I keep getting surprised about the amount of features and improvements that are doable with little effort. When I look at the code in lxml, for example, I constantly notice hand written tweaks that are no longer necessary today, simply because Cython got so much better over the last year or so. You can really feel what it buys you to fix the code generator instead of the code itself. > Or put another way: Putting relatively little in can, at least at this > point in Cython's development, yield high returns. > > Example: Profiling was a feature many at SciPy was anxious about > getting and was asking about a lot. That's in trunk now, mainly because > Robert had an intercontinental flight (!!). (That admittedly might say a > lot more about Robert than Cython, but still.) One problem I see here is the current release schedule. We keep getting more and more away from the "release early, release often" principle. Getting 0.12 out in one way or another would finally make all the great trunk improvements available to regular users. Thing is: every release needs a driver, so that's the first place where we could benefit from a dedicated helping hand. I mean, Sun pays the Jython project lead, even full-time. Guido is payed half-time for CPython evolution. I wonder if there isn't enough commercial interest in Cython by now that could express itself in contributed project time or financing. A developer day invested in Cython development can easily pay off by making your own code easier to write and/or faster to execute. Remember, we write C so you don't have to! (maybe we should put the last two sentences on the front page ;) > Cython can thrive without this too though! Looking at the coming > half-to-three-quarter year, here's what I'm guessing will happen: > > - I might get the new memoryviews from summer finished and merged with > trunk I wouldn't mind putting major new features off for 0.13 and releasing 0.12 sooner. > - Cython might run properly in Python 3 (w/ 2to3) It almost does, except for two remaining bugs. Even the test runner works out of the box now. > - Get -unstable stabilized and released (significant portion) I'm all for making that the current priority. I even consider it mostly stable, except for the few failing test cases (well, and for the open bugs that lack a test case, obviously). > - Fwrap released Independent of Cython's own schedule, except if there's a requirement for better integration on Cython side (which would be fine for 0.13). > - Closures > - Better C++ support merged > - Perhaps some pyximport improvements Again, fine for 0.13. While I guess that much of this done, I honestly prefer a soon-to-be-outdated release over ever-lasting developer checkouts. > Not bad at all! But, there's also a long list of projects we already > badly want to have done that we can't possibly reach now, IMO: > > - Fix the bugs, complete the test suite Oh, well... ;) I split up the following list into major enhancements that need real work and will arrive as major new features: > - SIMD > - Control flow analysis! > - Type inference/a better pure Python mode (note that type inference pretty much depends on control flow analysis) and those that will continue to improve through applied spare time: > - Speed up compilation speed, break up compilation units/utility code > - Convenient debugging, line-by-line profiling > - Many rather low-hanging fruit CEPs which would make using Cython a > nicer experience > - Full Python semantics compatability for untyped code Major new features (even the "we know how to do it" ones) will certainly require more than the average spare time of the current core developers. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
