On Thu, Mar 28, 2013 at 09:51:46AM -0700, Mehdi AMINI wrote: > Hi, > > >2/ take it into account in addition to export commands when running > >pythran, but generate a file.pyc holding non-pythran code, and a > >_file.so loaded by the pyc to implement the native functions (I like > >this option) > > > >3/ use it as a real generator and dynamically run the compiler, > >hopefully using a cahce to avoid calling the compiler twice, and > >apologizing for the slowness of c++ compilation (I like this option > >inside ipython, but not otherwise) It is compatible with 2/ > > If the compilation is persistent accross multiple run, I like this version! Me too :-) > > > > >I'll detail 2/ > > > > > ><<<input.py>>> > >import pythran > > > >def foo(a): return getattr(a,'pop') # not pythranic at all > >@pythran.native('int, int') > >def bar(a,b): return a%b > > > >After running pythran, we would get two files > > > ><<<input.pyc>>> which is the bytecode for > >from _input import bar > >def foo(a): return getattr(a,'pop') > > > >and > ><<<_input.so>>> which is the pythran compilation of > >#pythran export bar(int, int) > >def bar(a,b): return a%b > > You're proposal means changing the way Pythran module are generated, > with a python wrapper right? yes