On Tue, Feb 11, 2014 at 3:21 PM, CM <cmpyt...@gmail.com> wrote: > On Saturday, February 8, 2014 10:43:47 PM UTC-5, Steven D'Aprano wrote: > >> PyPy can generate code which is comparable to compiled C in speed. >> Perhaps you mean, "if execution speed is the most important thing, using >> a naive Python interpreter may not be fast enough". > > Given that the OP seems to be new enough to Python to not know what it is > not as good for, my guess is that PyPy may not yet be "ready enough" to > serve some/most of his needs. For example, if he wanted to write a GUI > app, AFAIK he is, for now, limited to Tkinter and a constrained section of > wxPython, and wxPython is dicey. I tend to see things through a desktop GUI > application lens, so maybe this is just my bias. And I hope I am wrong. I > am in no way trying to slight the PyPy efforts. > > Maybe he could somehow write the GUI part with CPython and the speed-critical > parts with PyPy but I don't know if that is possible. (Is it?)
More likely, he can write the whole thing in Python, and then run it in CPython. Then see if its speed is good enough. Sometimes "good enough" means "finishes executing in less than 100ms after user interaction". Sometimes it's even more generous. Other times it's "can handle at least X requests per second on a single CPU core", where X is defined based on the number of requests that the network can handle. If it meets that requirement, there's no reason to go to any sort of effort to improve performance. And that's how it is for huge HUGE numbers of Python scripts. Of course, if performance _is_ a problem, then the next step is to measure and find out exactly what's the slow bit. It's seldom what you first think of. ChrisA -- https://mail.python.org/mailman/listinfo/python-list