PyPy and wxPython

Hello, I would like to be able to use wxPython on PyPy.

I think some of you might be wondering why we should try to make wxPython run on PyPy. It gives us almost native speed. This means future wxPython programs could run much faster than they do now.

Example benchmark program:

def calculate_prime_numbers(highest_number):
    is_prime = False
    print(2),
    for n in range(3, highest_number):
        is_prime = True
        for x in range(2, n - 1):
            if n % x == 0:
                is_prime = False
                break
        if is_prime == True:
            print (n),

calculate_prime_numbers(100000)

This program calculates and displays all the prime numbers from 2 to 100,000. In regular Python (CPython) it takes 48.7 seconds to execute. Take the same program and run it in PyPy and execution time goes all the way down to 1.5 seconds. Try it yourself if you wish.

Why hasn’t wxPython been ported over to PyPy yet?
I think there are several reasons. One is a lack of organization. There is no official web site for supporting wxPython with PyPy. People have no where to go to find documentation on running wxPython on PyPy. Documentation can really help others to learn how he or she could help contribute to this cause. There is also no explanation on how wxPython would work in PyPy. Another reason is most people may not be aware that PyPy exists or even know what is its purpose. It would probably take a team of people to do the work. So far only a few individuals have tried.

Past attempts…
I have read a few post from people have did try to port wxPython over to PyPy. Here is one: building from source with PyPy. He reports having bad documentation, crashes, and code we could try. The link to his code is now dead.

How wxPython would work in PyPy (or what needs to be done)?
Currently I think it might work like this. Python calls will go thru CFFI to wxWidgets. So this:

PyPy <-> CFFI <-> wxWidgets

What I think should be done is an official website be made for running wxPython in PyPy. My suggestion is to use Sourceforge. It has a full forum for users to talk to each other, a file download section, and a ticketing system. If anyone has a better idea please let me know. I would like to make it as easy as possible for others to contribute.

Thank you.

I guess running primes is not a convincing incentive for changing a GUI framework :confounded:

1 Like

It was only an example benchmark. There are tons of programs that could benefit from the speedup PyPy provides.

Well yes, we already know that a pure-python program like “calculate_prime_numbers” will be faster on pypy. There’s no need of such a benchmark.

The real question is… would a wxPython program run faster? Ie, would wxPython draw a window with 100 buttons in a shorter time? No, it probably would not, since most of the workload is done by C extensions.

That said, you might be in a situation where you have a pure-python CPU-consuming task, and a GUI. Now, normally in wxPython you would put the task in a background thread, so to leave your gui responsive. Of course, threading in itself is not “solved” by pypy, since pypy is affected by the same notorious GIL issue as Python. However, wxPython releases the GIL when it’s running GUI-related (wxWidgets C++) code anyway, so a single background thread is usually not a bad idea in a wxPython program.
Would this scenario be improved by pypy? I think so, but I’m not really sure how pypy handles the threading machinery.

Anyway, as you can see in the other thread, Mattip is willing to give it a try… In the meantime, if you are in such a scenario, you may be better off with a multiprocessing solution.

1 Like

I am sure almost everyone has a Python CPU-intensive task and a GUI. This is the perfect scenario for using PyPy with wxPython. I don’t believe that the GUI itself will run fast but that isn’t really a problem. The GUI spends 99.99% of its time waiting for the user. The speed at which a combo box displays its contents usually is fast enough for the user. It is the CPU-intensive tasks that will really make PyPy shine. Users will see a considerable increase in application speed with it. The difference in speed would be like replacing your car’s V6 engine with a warp drive :wink:

This is the location for the project to make wxPython work on PyPy: GitHub - pypy/wxpython-cffi: Experiment in getting SIP to emit cffi code

and if you choose multiprocessing the SimpleQueue is usually sufficient, or try SharedMemory (after all it’s only a flickering to the GUI) :wink:

The SimpleQueue is only concerned about when to schedule code to run. PyPy is all about how fast the code will run.