On Tuesday, October 1, 2013 8:15:21 PM UTC+2, Joachim Durchholz wrote: > > That's a good thing, though they'd still have to upgrade the system with > each new Python version, so it's not buying the project THAT much. >
Well, that's partially true. Compared to PyPy, Jython, IronPython and Cython, I think that work in Nuitka is minimal, as the language interpreter is Python's own ast library. The other alternative interpreters often reimplement again the whole of Python's language. But yes it makes sure that no deviations creep into the parsing, which > is good. PyPy's problem is that not all of Python's code is compatible, and the same is true for Jython and IronPython. Cython instead should be able (I think) to compile almost all of Python, but if you want to use static typing, you need to use *cdef*, which breaks compatibility with CPython. In a few words, PyPy restricts the Python standard language, Cython extends it. Nuitka is very interesting because it neither restricts nor extends the Python language. Besides, they plan to add static typing upon translation to C++ without breaking compatibility (it is suggested to use decorators). Here are some considerations by Nuitka's developers: http://nuitka.net/posts/static-compilation-that-is-the-point.html The main question, then, is: Is Nuitka viable? > I.e. is it going to stay around as long as Sympy will? How fast do they > fix showstopper bugs? Are type decorators and (hopefully) something > smart for the data representation going to be implemented within our > lifetimes? Nuitka is relatively young as a project (I suppose around 2 years old), and it is already able to compile almost every python library (at least so they claim). Their first aim was to achieve an almost 100% compatibility with CPython, after that, their second step will focus on performance. As far as I know, they have just finished the compatibility part. Let's see what is coming out of it in the future. It looks like a great replacement for both PyPy and Cython. Alternatively, we could do our own Python-to-C++ translator. This would > be easier than a full-fledged translator because we'd have to cover only > those constructs that are actually used in Sympy, so we could take > considerable shortcuts (at the cost of needing a list of coding > restrictions, so this option would still come with attached strings). > That would be a lot of work. In any case, regarding a possible construction of our own translator, I would suggest to use Nuitka still, then compile its C++ result to XML using *gccxml*, applying transformation rules to the XML-equivalent C++ code, and then transforming back to C++. XML has a lot of parsers, tree walkers, interpreters. C++ instead is hard to edit as it is. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To post to this group, send email to sympy@googlegroups.com. Visit this group at http://groups.google.com/group/sympy. For more options, visit https://groups.google.com/groups/opt_out.
