wxPython / Your Experiences in large project ???

F. GEIGER fgeiger at datec.at
Sat Apr 13 12:07:16 EDT 2002


Hi Chris,

> 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.

How did you find, *where* this happend and how did you solve this problem?
Did you deactivate gc (don't know if it's possible)?.

Best regards
Franz


"Chris Spencer" <clspence at one.net> schrieb im Newsbeitrag
news:vnq3buoibt8lbqlhi4vjoo4qobgfl6hi0v at 4ax.com...
> 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
> >
>





More information about the Python-list mailing list