Dag Sverre Seljebotn, 15.07.2010 10:24: > On 07/15/2010 07:27 AM, Robert Bradshaw wrote: >> We'd certainly like to support function-level compilation (though >> there are technical questions about how to get the source) and perhaps >> even line-by-line via strings.
+1 for function level compilation through a decorator. Shouldn't be hard to do at all, as long as we have the code readily available (i.e. the .py file, not just a .pyc file or something). It would be a nice additional feature to compile the code from a string instead of a file in that case, and to report the line number offset correctly. >> Right now the Sage notebook gives this >> feel for Cython, which is probably why I haven't felt the pinch (I >> rarely write and invoke a setup.py manually). Yes, the Sage notebook is a really nice little front-end for Cython development. Almost like an interactive shell. The sick thing is that you have something in the GB range on your hard drive just to run a little web app that compiles and runs code... Now that I say that, what about IPython support for Cython compilation? ICython, anyone? > Here's some work which gets the source from decorated functions (in pure > Python...the decorator could extract source, compile with Cython, and > replace the decorated function with one imported from the compiled one): > > http://github.com/GaelVaroquaux/joblib/blob/master/joblib/func_inspect.py Looks a bit funny. Wouldn't inspect.getsource() be enough for the beginning? The comments in the above code seem to suggest that the only reason not to use inspect is that the source file can change on the fly. I would expect that users would normally restart Python when they modify the sources and want them to get recompiled ... > Of course this requires a stronger pure Python mode. Agreed, although the current state of the pure Python mode is certainly not a reason to wait with providing this feature. >>> 3) The C-source-in-a-string is pretty ugly, I admit. Weave is very >>> far on the "practicality" side of the "practicality vs. purity" scale. >>> It is a small benefit, though, to have the C/C++ code quarantined to >>> one place in a function, and to always know exactly what to expect >>> from each part of your code -- python remains python, C remains C. >>> The fluidity of Cython is a tremendous advantage, but it does require >>> some care to be sure you're typing everything that needs to be typed, >>> turning off boundschecking when it's safe, etc. I tend to use 'cython >>> -a' or inspecting the generated source to be sure I'm "totally C" >>> fairly often. Weave gives this to you automatically. In short, with >>> weave, I don't have to pay attention as much to get the same degree of >>> performance. The tradeoff is ugly code. >>> >> That's a good point--we should be a lot closer with type inference >> (and especially if we do the trick of compiling/specializing the code >> at runtime to the input types) but the fact that untyped code is just >> slower rather than broken is an interesting one. Almost makes me want >> to have a "C only" flag or something like that. >> > We already discussed having a decorator for disallowing untyped > variables. Basically you would need to type every variable in a > function, but typing as "object" would be OK. I think this is more > useful than "C only" in this context. Yes, makes sense to me. I remember that it was Lisandro who pushed for this at the time, and I had it in the back of my head that this had been implemented at some point. It seems not. Stefan _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
