On Thu, Jul 15, 2010 at 2:15 PM, Stefan Behnel <stefan...@behnel.de> wrote: > 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.
Yep. >>> 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... Here's a nickel. (OK, that won't quite get you a GB, but close...) > 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 ... I think the trickier part is getting it from am interactive prompt, though IPython has done most of the hard work in this direction. >> 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. Pure python mode is enough to do quite a bit here, and the stuff like cdef classes/methods are harder to take advantage of locally as well. (Future direction--letting the second decorated function be aware of everything that came before it and able to invoke it via c semantics, kind of an auto-cimport?) >>>> 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. Nowadays that would be trivial to do. Any ideas for a directive name? - Robert _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
