Magnus Lie Hetland wrote: > As mentioned in a couple of previous emails, I've been experimenting > with pure mode lately, with the main motivation being the use of > development tools (coverage, lint etc.). I'm sure I can get that to > work, but I also sort of like the plain Cython syntax :-) So an > alternative occurred to me: Building plain Python from Cython. > > IOW, I could just strip down the Cython code to get plain Python > equivalents that I could use the dev-tools on. Is that just a silly > idea? Would I be better off with pure mode? (Is there, perhaps, such a > beast/processor somewhere? I'm assuming I could reuse the Cython > parser if I needed to write something myself?)
No, it's a good idea (though see below). The work is about 1/3 done I think... Compile/CodeWriter.py contains a tree transform which will serialize the tree back to Cython code which should be a good starting point (it only supports parts of the language currently though) -- it can simply have a flag or subclass to skip any type declarations, output cdef classes as py classes etc. To quickly test with it, plug an instance into the pipeline (search for "pipeline" in Main.py). (If a proper tool is developed one should set up a seperate pipeline for the tool. In the devel branch I have been doing some refactorings so that there's a seperate Pipeline.py.) > > I guess this might be useful also if people have already written > Cython code that they'd like to have in plain Python form (although > much, if not most, Cython code probably includes wrapping stuff that's > not easy to translate... I mainly use it to implement algorithms for > experiments). > > From the other perspective, if I'm going to go for pure mode, I'd > appreciate being able to keep the Python files to be compiled as > simple as possible (i.e., with as little explicit declarations as > possible). I'm guessing that associated pxd files, along with CEP 505 > could make that possible, if I code carefully. How likely do you think > it is that that CEP (or some equivalent) will be accepted? (I'm > guessing it would be hard to make that handle Cython/numpy arrays, > though...?) I have lots of thoughts on pure Python mode :-) (but I'm mostly restraining myself until there's a good chance that somebody has time to actually implement something). First, as for NumPy arrays, it should be possible based on function argument decorators. Also with the new memoryview syntax, this could work in both Python and Cython: import cython view = cython.int[:,:](my2darray) print view[3,4] # fast when compiled My vote is always in favour of solutions that make Cython appear almost like a library in Python code -- with the difference being that use of the library is faster when compiled. E.g., for cdef classes I'd like a solution based on declaring interfaces with Python 3's Abstract Base Classes, and so on. (Don't tempt me, I have a whole CEP on this sitting in my head but I should spend my time better than writing it down...) > And another thought/idea: What about allowing further declarations in > the .pxd file (or some similar mechanism)? I.e., declaring local > variables? Might seem pointless, but the idea would be to allow the > compilation of optimized C from a plain Python file without any signs > of Cython declaration. (This could then even be done with Python code > you're not allowed to modifo.) I.e, you could specify all metadata > separately. (If CEP 505 were accepted, this would only be needed in a > few cases, I guess. Maybe?) I think declaring local variables is already allowed in pxd files, it's just not documents. I think @cython.locals(localvar=cython.int) cpdef foo(int x) in the pxd file should work. Not that pretty though...perhaps stick to @cython.locals(localvar=cython.int) cpdef foo(cython.int x) for better readability. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
