wxPython / Your Experiences in large project ???

[Chris Spencer]

	Okay, I guess I should chime in here.
	I am a professional developer for a small software company.  My company
has been using Python for its projects for the past 18 or so months.  We have a
whole product suite written in Python.  Until recently, this product was 95%
console driven, even on our Windows port.  Customers have been asking for a GUI
to tie all the parts of our product together.
	For the past month, I have been developing a GUI Administrator program
for our product using wxPython.

Some statistics:
Code is hovering around 6000+ lines in 12 modules
Approx. 60% of that code is directly related to wxPython
Development time in man-hours: 280

Pros:
1.  It has incredible flexibility.  I've done some pretty weird stuff that I'd
plain just be afraid to try in MSVC++.
2.  Rapid development.  This project would've taken me nearly a year to do in
C++/MSVCRT.  At a ROUGH guess, it would've hovered around 30,000-40,000 lines.
3.  Robust library.  I used to dive into www.codeguru.com to grab source code
for custom controls so I could modify them to my needs.  I've felt no real
reason to "build" new controls to suit my needs with wxPython.
4.  Maintainability.  Those 6000 lines of code I've done are all pretty much in
the category of "self-documenting code".

Cons:
1.  BAD documentation.  They've taken the wxWindows library documentation, added
a few notes, and called it the wxPython documentation.  And the thing is, they
haven't kept it updated for more recent releases of wxWindows/wxPython, so
there's a lot of undocumentated features that just don't show up.  I had to
start using the wxWindows docs from the wxwindows site, and interpret (and
source-code dive) what a reasonable wxPython equivalent would be.  LOTS of
trial-and-error.

2.  This project would've taken half the time it eventually took if wxPython was
either documented better, or took greater pains to protect the pointers that
wxWindows sometimes uses.  I'm in Python fer chrissakes, I shouldn't care about
null pointers.  Yet the grid control kept GPF-ing on me for weeks until I
figured out that Python was "blowing away pointers" behind the scenes for
garbage collection.

3.  Bloat.  The support files alone for my program (the wxWindows .dll, the
wxPython .pyd files, etc) amount to about 6 megs of space.  The program's BASE
memory usage upon startup is 14 megs.  This might not seem so bad for a 6000+
line program until you realize that a *100* line program would STILL take up 14.
megs of memory.

4.  Did I mention that the documentation is both incomplete and odious?  I
should not have to constantly do a "find in files" to find out what parameters a
damned method call takes because the way wxPython implemented a method is
different than the wxWindows way and someone forgot to make a note of it in the
rubbish passed off as a "manual".

5.  I've had a REAL problem with conservative "window refreshes", where unless I
specifically tell each window to repaint itself, I get a lot of scroll bars
missing, a lot of windows being "grey" (shown without controls), Tab windows
without the tab headers, etc.  wxWindows/wxPython should be more aggressive
about repainting windows.  Even MCVCRT controls are better about repainting
themselves without having to be told that their render clipping planes are
dirty.

	The pros outweight the cons by a WIDE margin once you've climbed the
learning curve.  While on that slope, though, the lack of robust and complete
documentation will HURT you.

Chris.

On Mon, 8 Apr 2002 11:55:24 +0200, "Harald Schneider"
<h_schneider at marketmix.com> wrote:

>Hi,
>
>what are your experiences, using wxPython/wxWindows in large projects?
>
>Large means in my case a sales system, based on MySQL.
>I'm thinking about implementing it in wxPython, but I'm not sure about the
>stability of
>wxWindows and the wxPython wrapper ...
>
>The alternative way would be a project in Borland Delphi, which has proofed
>its
>stability over years ...
>
>So what do you think about it!
>
>Thanks a lot,
>Harald
>