FAQ
Hey all,

Anyone have any experience using Pythonas an alternative to VB for Windows
database client apps? It looks like all the pieces are in place -
wxWindows, py2exe, a Python ADO library...

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.

Thanks for any pointers, anecdotes, etc.

--
Robb Shecter
Senior Software Engineer
www.onsitetech.com

Search Discussions

  • Jeff Shannon at Mar 29, 2002 at 11:11 pm
    In article <a82lnn$gdu at dispatch.concentric.net>,
    rs at onsitetech.com says...
    Hey all,

    Anyone have any experience using Pythonas an alternative to VB for Windows
    database client apps? It looks like all the pieces are in place -
    wxWindows, py2exe, a Python ADO library...

    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.
    Well, I don't have any direct experience with writing database
    clients, nor with using the full VB development environment, but
    from what I have gathered...

    Pure GUI development in VB is likely to be a bit easier, because
    the VB environment is (I have heard) quite polished, and allows
    you to do an awful lot with simple 'painting'. There are some
    graphical designers for wxPython (notably wxDesigner and Boa
    Constructor), but I don't think that either is up to the level of
    VB's.

    Of course, you *do* get all the advantages of working in Python
    over working in VB. If you're doing any significant amount of
    processing of the data within your client, I'd think that this
    advantage would outweigh VB's graphical designer's benefits.

    As for py2exe, my personal feeling is that it's usefulness is
    limited unless you're likely to distribute it to a significant
    number of workstations, and those workstations cannot be expected
    to use Python for any other purpose. In my own situation, I'm
    unlikely to distribute any of the software that I'm working on to
    more than half a dozen machines, and on several of those I'm
    likely to want to use Python for a number of projects. As a
    result, it's not difficult for me to ensure that Python is
    functioning on all my target machines, and I can distribute code
    as distutils packages, which saves having a separate interpreter
    for every application I'm creating. Whether py2exe is worth the
    effort for you, will depend on your specific circumstances -- if
    you're wanting to put no more than one or two Python applications
    on a relatively large number of machines, or simply have
    little/no control over the machines it should run on, then py2exe
    would be a lot more useful.

    Hope this helps...

    --

    Jeff Shannon
    Technician/Programmer
    Credit International
  • David Bolen at Mar 30, 2002 at 1:38 am

    "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 \
    \-----------------------------------------------------------------------/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedMar 29, '02 at 9:18p
activeMar 30, '02 at 1:38a
posts3
users3
websitepython.org

People

Translate

site design / logo © 2022 Grokbase