On Dec 9, 10:43 pm, "Jack" <[EMAIL PROTECTED]> wrote: > > http://blog.snaplogic.org/?p=55
There's some choice nonsense here, albeit on a different topic: "Coding for wxwidgets, using a QT or GTK bridge, or using TCL/TK is hardly an optimal solution when writing complex graphical applications, and Java wins in this area, despite there comically being many problems with the look and feel of Java applications." Clearly an individual who hasn't actually used any of the Python GUI development solutions, given the choice of words: "bridge", "hardly an optimal solution"; virtually intimating that you'd be doing malloc/ free or new/delete all the time. Plus throwaway remarks of the form "XYZ wins" tend to suggest beliefs with little substance and a continual need for self-reassurance on such matters. Anyway, back to the topic at hand... > Here's an article that shows the new version of Ruby is > faster than Python in some aspects (they are catching up :) > > http://antoniocangiano.com/2007/11/28/holy-shmoly-ruby-19-smokes-pyth... It's evident that the next mainstream version of Ruby will have various optimisations around recursive operations - something that has generally been rejected for CPython. Of course, the mainstream Ruby implementation has had a lot of scope for improvement: http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=all What disappoints me somewhat is that most of the people interested in taking Python performance to the next level are all outside (or on the outer fringes of) the CPython core development group: PyPy and Shed Skin are mostly distinct technologies; Psyco integrates with CPython but hasn't improved the "out of the box" situation; Pyrex is really a distinct tool, being more like a convenient wrapper generator than a bolt-on high performance engine for CPython. Language implementations like that of Lua have seen more progress on integrating solutions for performance, it would seem. As for a C-Python of the form requested, I suppose tools like Shed Skin and RPython fit the bill somewhat, if a transparent solution is needed where one writes in Python and it magically becomes fairly efficient C or C++. Otherwise, Pyrex provides more explicit control over what gets written in C and what remains in Python. Paul -- http://mail.python.org/mailman/listinfo/python-list