MFC application and Python

[Adal Chiriliuc]

Hi.

I'm working on a C++ Win32 MFC application and I want to move as much
code as possible to Python.

At first I wanted to use a Python GUI package and keep the critical
components (performance wise) in C++ extensions. The application must
have a native look so this leaves us with only two choices.

wxPython is way too bloated (9 MB on disk, 20MB! in memory for basic
stuff) and people say buggy. PythonWin is nice and small, but lacks
some features, like GDI support.

So this gave me the idea of doing it the other way around: having a
skeleton application which handles Win32 messages and the application
threads and this will call into Python for the logic, which will call
back into C++ for the critical operations and GUI updates.

Since I'm new to Python, can you see any problems with this approach?
Is there a better way to do it?

A specific question: is it ok if C++ calls into Python which calls
into C++ which calls again into Python and so on let's say 5 levels
deep as reaction to a Win32 message or a thread unblocking?

And another one: What are the ways to call into Python? I know of
PyRun_, PyObject_Call and boost:ython::call.

Regards,
Adal Chiriliuc

 

[Doug Holton]

I'm working on a C++ Win32 MFC application and I want to move as much
code as possible to Python.

At first I wanted to use a Python GUI package and keep the critical
components (performance wise) in C++ extensions. The application must
have a native look so this leaves us with only two choices.

wxPython is way too bloated (9 MB on disk, 20MB! in memory for basic
stuff) and people say buggy. PythonWin is nice and small, but lacks
some features, like GDI support.

If you're already coding in C++, and think wxPython is too bloated, and
you were prepared to use pythonwin (win32gui) if only it had more
features, then I'd say stick with C++, it's not much more difficult than
using win32gui and will allow you to make your application as fast and
lightweight as you like.
But if you seriously want to switch to Python, then I'd reconsider
wxpython. It is the best python GUI toolkit for your specific purposes
I think. It isn't buggy.

 

[Neil Hodgson]

Adal Chiriliuc:

wxPython is way too bloated (9 MB on disk, 20MB! in memory for basic
stuff) and people say buggy. PythonWin is nice and small, but lacks
some features, like GDI support.

At least some of GDI is available. I wrote some of the printing code
inside PythonWin and there are calls like dc.GetTextMetrics, dc.SetMapMode,
and dc.TextOut.

So this gave me the idea of doing it the other way around: having a
skeleton application which handles Win32 messages and the application
threads and this will call into Python for the logic, which will call
back into C++ for the critical operations and GUI updates.

Venster and ctypes may be of interest. Venster doesn't appear very active
but was updated as recently as January.

Neil

 

[Dave Brueck]

I'm working on a C++ Win32 MFC application and I want to move as much
code as possible to Python.

At first I wanted to use a Python GUI package and keep the critical
components (performance wise) in C++ extensions. The application must
have a native look so this leaves us with only two choices.

wxPython is way too bloated (9 MB on disk, 20MB! in memory for basic
stuff) and people say buggy. PythonWin is nice and small, but lacks
some features, like GDI support.

You might consider using ctypes as it lets you call pretty much any Windows
API. If you are familiar with rather low-level Win32 GUI programming, Venster
(a pure Python package built on top of ctypes) provides a good head start - at
my company we've used it in several places and have found it to be a good
alternative when app size is an issue, or when we're not really interested in
anything but a Win32 deployment.

-Dave