Quality assurance in Python projects containing C modules

[NoelByron]

Hello!

We are thinking about writing a project for several customers in
Python. This project would include (among others) wxPython, a C/C++
module. But what happens if this application generates a segmentation
fault on a customers PC. What changes do we have to trace back the
source of the error? Imagine you use two or three C libraries in a
Python project and you experience random crashes in 'Python.exe'. What
would you do?

We intent to target mainly the Windows platform. Is there for example
a way to use 'dbghelp.dll'?

Best regards and thank you!
Noel

 

[Duncan Booth]

Hello!

We are thinking about writing a project for several customers in
Python. This project would include (among others) wxPython, a C/C++
module. But what happens if this application generates a segmentation
fault on a customers PC. What changes do we have to trace back the
source of the error? Imagine you use two or three C libraries in a
Python project and you experience random crashes in 'Python.exe'. What
would you do?

I would start by ensuring that any DLLs you write are written using Pyrex
or Cython: almost always problems with C libraries called from Python are
due to faulty reference counting but if you keep all of your Python related
code in Pyrex/Cython modules the reference counting problem should be taken
care of for you. You can call any required C/C++ code from the Cython code.

 

[Stefan Behnel]

I would start by ensuring that any DLLs you write are written using Pyrex
or Cython: almost always problems with C libraries called from Python are
due to faulty reference counting but if you keep all of your Python related
code in Pyrex/Cython modules the reference counting problem should be taken
care of for you. You can call any required C/C++ code from the Cython code.

I think the OP meant to use wxPython as an external module, in which case he
has no way of influencing the language it is implemented in.

My personal experience with wxPython has its ups and downs. Specifically when
it comes to crashes, I wouldn't bet my life on it. (but then, the OP aims for
using Windows anyway, so maybe there are ways to hide the crash of wxPython
behind a full-fledged system crash to avoid being blamed...)

Stefan

 

[Malcolm Greene]

Stefan,

My personal experience with wxPython has its ups and downs. Specifically when it comes to crashes, I wouldn't bet my life on it. (but then, the OP

I'm new to Python and getting ready to build a small client based
application intended to run on Windows and Linux. I was planning on
using wxPython until I saw your comment above.

Any suggestions on an alternative Python client-side GUI library (pyQT
?) or tips on where I can find out more about wxPython/wxWidget
problems?

Thank you,
Malcolm

 

[Mike Driscoll]

Stefan,


I'm new to Python and getting ready to build a small client based
application intended to run on Windows and Linux. I was planning on
using wxPython until I saw your comment above.

Any suggestions on an alternative Python client-side GUI library (pyQT
?) or tips on where I can find out more about wxPython/wxWidget
problems?

Thank you,
Malcolm

We use wxPython here at work for new application development and have
had no major problems with it once we knew what dlls to include. In my
experience, I've needed gdiplus.dll, msvcp71.dll and MSVCR71.dll from
time to time.

Mike

 

[Duncan Booth]

I think the OP meant to use wxPython as an external module, in which
case he has no way of influencing the language it is implemented in.

The OP mentioned 'two or three C libraries', so I assume wxPython is only
part of the story.

 

[Stefan Behnel]

I'm new to Python and getting ready to build a small client based
application intended to run on Windows and Linux. I was planning on using
wxPython until I saw your comment above.

Just to make this sound a bit less like FUD: my last experience with wxPython
dates back a couple of years (2004/5?), but back then, we used BoaConstructor
in a project, which crashed a bit too often to do real work with it - and with
crashing I mean crashing Python, not just showing us its blank traceback. So
this was definitely a problem either in wxWindows or in wxPython.

I have no idea how well it works today, but this has definitely forged my
opinion on wxPython.

Any suggestions on an alternative Python client-side GUI library (pyQT ?)
or tips on where I can find out more about wxPython/wxWidget problems?

The only other GUI library I used was PyQT3. To me, it has proven to be very
stable, pretty easy to use and feature rich. And from what I read about it,
PyQT4 is supposed to be another lot better and has removed the few API quirks
I found at the time (AFAIR, it finally returns plain Python strings from the
API, for example).

Stefan

 

[Stefan Behnel]

The OP mentioned 'two or three C libraries', so I assume wxPython is only
part of the story.

Ah, sorry, I missed that. Sure, if it's about integrating C/C++ libraries as
Python modules, then I second the recommendation of using Cython.

Stefan

 

[Stef Mientki]

Just to make this sound a bit less like FUD: my last experience with wxPython
dates back a couple of years (2004/5?), but back then, we used BoaConstructor
in a project, which crashed a bit too often to do real work with it - and with
crashing I mean crashing Python, not just showing us its blank traceback. So
this was definitely a problem either in wxWindows or in wxPython.

I have no idea how well it works today, but this has definitely forged my
opinion on wxPython.

I'm using wxPython for half a year now, and building quit a large /
heavy GUI with it.
And although it's not so easy as Delphi, it's certainly just as stable
as Delphi.

If you're talking about Boa, that's a completely different story,
I tried it on 3 different machines, and couldn't get it working on any
of them.
I think Boa / Dabo / .. are basically good ideas to make programming
wxPython more easy,
and probably a lot of people invested a lot of their free time in the
product with the best intentions,
but unfortunately these programs are not ready for use by others
(specially not for windows users).

I'ld suggest that you download the wxPython demo (with interactive
editor) and see for yourself.

cheers,
Stef

 

[Mike Driscoll]

Just to make this sound a bit less like FUD: my last experience with wxPython
dates back a couple of years (2004/5?), but back then, we used BoaConstructor
in a project, which crashed a bit too often to do real work with it - and with
crashing I mean crashing Python, not just showing us its blank traceback. So
this was definitely a problem either in wxWindows or in wxPython.

I have no idea how well it works today, but this has definitely forged my
opinion on wxPython.


The only other GUI library I used was PyQT3. To me, it has proven to be very
stable, pretty easy to use and feature rich. And from what I read about it,
PyQT4 is supposed to be another lot better and has removed the few API quirks
I found at the time (AFAIR, it finally returns plain Python strings from the
API, for example).

Stefan

I agree with Stef. Boa is definitely goofy and while I know some
people swear by it, I see far too many people having issues. I go with
hand coding or XRC. Some also like SPE, but I haven't tried that to
know.

Mike

 

[kperkins257]

I agree with Stef. Boa is definitely goofy and while I know some
people swear by it, I see far too many people having issues. I go with
hand coding or XRC. Some also like SPE, but I haven't tried that to
know.

Mike

SPE is actually a very good editor--I'm using it for all my Python
coding. It integrates well with wxglade, and wxpython, and is built
on wxpython. I've used wxpython on a couple of little projects, and
it works very well (on Linux, anyways). I'm starting a couple of
bigger projects now, and am confident that it will scale up, seeing
some of the projects that are using it.
I've tried Boa a couple of times but, for me, the interface sucks, and
is not very intuitive.

 

[Benjamin]

Just to make this sound a bit less like FUD: my last experience with wxPython
dates back a couple of years (2004/5?), but back then, we used BoaConstructor
in a project, which crashed a bit too often to do real work with it - and with
crashing I mean crashing Python, not just showing us its blank traceback. So
this was definitely a problem either in wxWindows or in wxPython.

I have no idea how well it works today, but this has definitely forged my
opinion on wxPython.


The only other GUI library I used was PyQT3. To me, it has proven to be very
stable, pretty easy to use and feature rich. And from what I read about it,
PyQT4 is supposed to be another lot better and has removed the few API quirks
I found at the time (AFAIR, it finally returns plain Python strings from the
API, for example).

No, it still returns QStrings, so it doesn't break tons of code. I
just always convert it to unicode if I'm going to keep the string
around.

 

[Gilles Ganault]

Any suggestions on an alternative Python client-side GUI library (pyQT
?) or tips on where I can find out more about wxPython/wxWidget
problems?

One thing that bothers me is that it seems like there's no ecosystem
around it, so the only widgets available are those that come from
wxWidgets proper.

For instance, I find the grid object a bit poor-featured compared to
what's available for VB6, .Net, or Delphi, but I didn't find
alternatives.

 

[Frank Millman]

One thing that bothers me is that it seems like there's no ecosystem
around it, so the only widgets available are those that come from
wxWidgets proper.

For instance, I find the grid object a bit poor-featured compared to
what's available for VB6, .Net, or Delphi, but I didn't find
alternatives.

I do not know if this helps, but here is an extract from a recent post
to the wxPython mailing list from Robin Dunn, the main developer of
wxPython -

"The new wxDataViewCtrl coming in 2.9 might make this unnecessary.
Think of it as a wxListCtrl that is always in virtual mode with a plug-
in data model, can optionally have hierarchical data (like wxTreeCtrl)
in one of the columns, and where every column can have a custom
renderer/editor for the cells like wxGrid. And it uses the native
controls on Mac and GTK. I've been working on the wrappers for it off
and on over the past few weeks and while it is a complex beast, it
will probably be easier to use than wxGrid in most cases and easier
than wxListCtrl in some cases too."

I also strongly recommend using the mailing list for any questions,
problems, or feature requests. Robin is a very active contributor to
the list, and frequently provides very insightful answers. Also there
are a number of other active contributors, some of whom have designed
their own composite widgets using the underlying components of the
toolkit, and are happy to share them.

Frank Millman

 

[NoelByron]

Hi Malcom

I'm new to Python and getting ready to build a small client based
application intended to run on Windows and Linux. I was planning on
using wxPython until I saw your comment above.

We use wxPython and Python internally in the company without any mayor
problems or crashes. It seems quite solid. But errors happen in
complex systems. And if for example a crash occurs it would be good to
know the reason and to track it down. And that is hard in Python with
C extensions. That does not only apply to wxPython but to all other
(GUI) libraries with C parts, too. At least we will not switch to
something else then wxPython.

Best regards,
Noel

 

[Gilles Ganault]

I do not know if this helps, but here is an extract from a recent post
to the wxPython mailing list from Robin Dunn, the main developer of
wxPython -

I'll take a look. Thanks for the info.

 

[Stef Mientki]

One thing that bothers me is that it seems like there's no ecosystem
around it, so the only widgets available are those that come from
wxWidgets proper.

For instance, I find the grid object a bit poor-featured compared to
what's available for VB6, .Net, or Delphi, but I didn't find
alternatives.

Funny, compared to Delphi-7,
I found the grid in wxPython much richer ;-)
Very easy to add own in place editors,
easy add checkboxes, colorpickers etc into the grid.

cheers,
Stef

 

[Sion Arrowsmith]

Just to make this sound a bit less like FUD: my last experience with wxPython
dates back a couple of years (2004/5?), but back then, we used BoaConstructor
in a project, which crashed a bit too often to do real work with it - and with
crashing I mean crashing Python, not just showing us its blank traceback. So
this was definitely a problem either in wxWindows or in wxPython.

I spent a couple of years maintaining and developing a series of
commercial wxPython-based applications (up until about 18 months ago
when I changed job), and I would happily describe wxPython itself as
stable enough for production code. The biggest problem I had with it
was its failure to be anywhere near as transparently cross-platform as
one might be lead to expect.

And before you blame wx* for crashes: what platform was this on?
Because my experience was that wx on GTK was significantly more prone
to glitches than on Windows (through to wxglade being unusably crashy)
-- if the underlying toolkit has problems, that's going to be
reflected in wx.

 

[Stefan Behnel]

And before you blame wx* for crashes: what platform was this on?
Because my experience was that wx on GTK was significantly more prone
to glitches than on Windows (through to wxglade being unusably crashy)
-- if the underlying toolkit has problems, that's going to be
reflected in wx.

Interesting. This was actually on GTK. Although I would still blame at
least the wxWidgets-GTK bindings here. I never had any problems with GTK in my
life.

Stefan

 

[Chris Mellon]

Interesting. This was actually on GTK. Although I would still blame at
least the wxWidgets-GTK bindings here. I never had any problems with GTK in my
life.

Gtk is much more finicky than windows about the timingof when you can
and cannot use certain functions. wxPython has checks in place for
many of these functions so you get an exception instead of a crash,
but not everything is safe (and of course in the past even fewer
things were). In particular, you need to have a wxApp object safely
constructed before you can use almost any gui object, which is not the
case under Windows.

wx makes the attempt to make correct code work correctly on platforms,
but doesn't necessarily guarantee that incorrect code fails the same
(or at all) on all platforms. This is an unavoidable compromise due to
the nature of a layering toolkit like this, although figuring out what
"correct code" actually is can take some experience.