Python+wxWindows as Visual Basic replacement?

[David Bolen]

"Robb Shecter" <rs at onsitetech.com> writes:

> Python per se isn't the issue - what I'm not sure about is what the
> development and deployment experience is like, when using these parts, taken
> together.

One caveat to get out of the way first - if it's a pure GUI front end
to database access, development will still be easier in the VB IDE for
GUI design, layout and so on.  You can improve on the Python side by
trying something like Boa, or the commercial wxDesigner for the
dialogs, but it's not really quite up to VB IDE levels yet.  There are
other IDE choices too for Python, but not many that attack the GUI
layout issue.

Personally, I just code directly in Python without any special GUI
designer, but that's how I've always done GUI coding - getting some
junior folks in my office who previously used VB to use Python has
been ok for non-GUI stuff, but they are clearly more productive in GUI
design under VB.

Of course, with the exclusion of GUI layout, Python, the language, is
IMHO superior to VB, although with a nice collection of components you
can get a lot of the same high level data constructs for use in VB
too.  But I find Python development itself more robust.

With the above caveat, the actual output of a Python+wxPython
application is just fine.  Looks and feels native, performs great, and
so on.  We're using it in a number of internal applications, and at
least one external application with others to follow.  And there are
some benefits to the wxPython approach over VB that may not be
immediately obvious.  When we evolved a simulation application from a
VB version into a later Python version, since the new GUI was designed
in wxPython with sizers, the primary screen that had been a fixed size
in the VB application, became resizeable "for free".  There are third
party controls to try to do this to a VB form, but it takes some work
and isn't the normal way of doing it in VB.

For deployment, we've used two approaches.  For our primary
distributed system (system installations across the country), Python
was made part of our standard system installation, including wxPython.
So any Python scripts or applications we develop for use on the
systems are simply deployed directly as Python source (or pyc files if
we want to save space).  The same mostly holds true for our internal
machines where our support group or internal users can install Python.

For general external deployment, we use the packaged approach (I use a
combination of Installer and InnoSetup, but py2exe is fine too).
True, it includes its own copy of the Python DLL and support files,
but it's guaranteed to work on the target system independent of any
prior installation, and it behaves just like the windows setup of an
application the users expect.  I've even taken this approach for a
couple of internal use (even non-GUI) tools that needed to be executed
on a few machines on which we weren't planning on installing Python,
so I could just copy the output distribution directory from Installer
to the target systems.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/