Just wanna say a quick thanks to all of you here, Very informative.
Thanks, On Sun, Oct 9, 2011 at 11:08 AM, Steven D'Aprano <st...@pearwood.info>wrote: > Walter Prins wrote: > > As for the compiler/interpreter argument, I'll just point out again that >> actually Python in its various forms can either be compiled and/or >> interepreted, it depends on you really. For compiled Python flavours, see >> for example Cython (http://cython.org/) which provides a way to write >> C/C++ >> modules for Python effectively in Python syntax. (Cython arguably also >> makes the "need to write wrapper" comment a moot point.) >> > > Cython is not Python. It is a separate language similar to Python, based on > Python, but not actually Python. It's actually a superset of Python. Any > Python code should be legal in Cython, but not all Cython code is legal in > Python. > > See, for example: > > http://docs.cython.org/src/**userguide/tutorial.html#primes<http://docs.cython.org/src/userguide/tutorial.html#primes> > > and notice that the Cython code: > > > def primes(int kmax): > cdef int n, k, i > cdef int p[1000] > # ... > > gives you a SyntaxError in Python. > > Credit where credit is due: Cython is a wonderful tool and very useful to > anyone wanting to write C extensions for Python, but it isn't Python. That's > not a limitation or a bad thing: it couldn't do what it sets out to do if it > were Python. > > > Or see Shedskin ( >> >> http://shed-skin.blogspot.com/**), a Python to C++ static compiler), >> > > > Shedskin, on the other hand, is a subset of Python: it can only work with a > restricted set of Python features. So also not Python. > > http://code.google.com/p/**shedskin/ <http://code.google.com/p/shedskin/> > > But still a very useful and valuable tool. > > > > or Psyco >> (http://psyco.sourceforge.net/**introduction.html<http://psyco.sourceforge.net/introduction.html>), >> a JIT (Just In Time) >> compiler for CPython. >> > > Psyco, on the other hand, is an add-on to Python: it runs inside the > CPython compiler, as an importable module, rather than being a separate > Python interpreter. > > > > Or see Pypy (http://pypy.org/) which is another >> reimplementation of the Python language with an optimizing JIT compiler. >> (The following post re realtime image processing in Python is rather >> impressive: >> http://morepypy.blogspot.com/**2011/07/realtime-image-** >> processing-in-python.html<http://morepypy.blogspot.com/2011/07/realtime-image-processing-in-python.html> >> ) >> > > > PyPy is very impressive, and it truly is an independent implementation of > Python, like CPython, Jython, IronPython and Stackless. It is faster than > CPython (although requires more memory) and in certain restricted > micro-benchmarks faster than C. > > Yes, faster than C. > > http://morepypy.blogspot.com/**2008/01/rpython-can-be-faster-**than-c.html<http://morepypy.blogspot.com/2008/01/rpython-can-be-faster-than-c.html> > http://morepypy.blogspot.com/**2011/02/pypy-faster-than-c-on-** > carefully-crafted.html<http://morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-carefully-crafted.html> > http://morepypy.blogspot.com/**2011/08/pypy-is-faster-than-c-** > again-string.html<http://morepypy.blogspot.com/2011/08/pypy-is-faster-than-c-again-string.html> > > > > This just goes to show that *languages* aren't faster or slower than other > languages. Languages just are. But *implementations* can be faster or > slower. > > > > -- > Steven > > ______________________________**_________________ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > http://mail.python.org/**mailman/listinfo/tutor<http://mail.python.org/mailman/listinfo/tutor> >
_______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor