470,581 Members | 2,433 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,581 developers. It's quick & easy.

Quality assurance in Python projects containing C modules

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
Mar 10 '08 #1
17 1437
No*******@gmx.net wrote:
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.
Mar 10 '08 #2
Duncan Booth wrote:
No*******@gmx.net wrote:
>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.
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
Mar 10 '08 #3
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
Mar 10 '08 #4
On Mar 10, 10:27 am, "Malcolm Greene" <pyt...@bdurham.comwrote:
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
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
Mar 10 '08 #5
Malcolm Greene wrote:
>My personal experience with wxPython has its ups and downs. Specifically
when it comes to crashes, I wouldn't bet my life on it.

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
Mar 10 '08 #6
Stefan Behnel wrote:
Malcolm Greene wrote:
>>My personal experience with wxPython has its ups and downs. Specifically
when it comes to crashes, I wouldn't bet my life on it.
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.
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

Mar 10 '08 #7
On Mar 10, 2:11 pm, Stefan Behnel <stefan...@behnel.dewrote:
Malcolm Greene wrote:
My personal experience with wxPython has its ups and downs. Specifically
when it comes to crashes, I wouldn't bet my life on it.
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
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
Mar 10 '08 #8
On Mar 10, 3:33 pm, Mike Driscoll <kyoso...@gmail.comwrote:
On Mar 10, 2:11 pm, Stefan Behnel <stefan...@behnel.dewrote:
Malcolm Greene wrote:
>My personal experience with wxPython has its ups and downs. Specifically
>when it comes to crashes, I wouldn't bet my life on it.
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

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.
Mar 11 '08 #9
On Mar 10, 2:11 pm, Stefan Behnel <stefan...@behnel.dewrote:
Malcolm Greene wrote:
My personal experience with wxPython has its ups and downs. Specifically
when it comes to crashes, I wouldn't bet my life on it.
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).
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.
>
Stefan
Mar 11 '08 #10
On Mon, 10 Mar 2008 11:27:06 -0400, "Malcolm Greene"
<py****@bdurham.comwrote:
>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.
Mar 11 '08 #11
Hi Malcom

On Mar 10, 4:27*pm, "Malcolm Greene" <pyt...@bdurham.comwrote:
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
Mar 11 '08 #12
On Mon, 10 Mar 2008 22:17:16 -0700 (PDT), Frank Millman
<fr***@chagford.comwrote:
>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.
Mar 11 '08 #13
Gilles Ganault wrote:
On Mon, 10 Mar 2008 11:27:06 -0400, "Malcolm Greene"
<py****@bdurham.comwrote:
>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.
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
Mar 11 '08 #14
Stefan Behnel <st*******@behnel.dewrote:
>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.

--
\S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
"Frankly I have no feelings towards penguins one way or the other"
-- Arthur C. Clarke
her nu becomež se bera eadward ofdun hlęddre heafdes bęce bump bump bump
Mar 11 '08 #15
Sion Arrowsmith wrote:
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
Mar 11 '08 #16
On Tue, Mar 11, 2008 at 11:01 AM, Stefan Behnel <st*******@behnel.dewrote:
Sion Arrowsmith wrote:
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.
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.
>
Stefan
--
http://mail.python.org/mailman/listinfo/python-list
Mar 11 '08 #17
On Tue, 11 Mar 2008 11:43:45 +0100, Stef Mientki
<S.**************@mailbox.kun.nlwrote:
>Funny, compared to Delphi-7,
I found the grid in wxPython much richer ;-)
You haven't tried the better alternatives I had in mind:

http://www.x-files.pl
http://www.bergsoft.net
http://www.tmssoftware.com
http://www.scalabium.com/smdbgrid.htm
http://www.tkweb.eu/en/delphicomp/kgrid.html
http://www.devexpress.com/Products/VCL/ExQuantumGrid/
Mar 12 '08 #18

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.