Python for Large Projects

[Ixokai]

Hello all. :)

    I've been a long time Python fan, and have fairly recently (with the
support of a coworker who surprised me by mentioning my pet language one
day) convinced my company to begin the colossal task of basically rewriting
all of our software in Python. Woohoo.
    Previously we used a few different development environments, mostly
Borland, for different products in our 'system' of thick clients sort of
operating with eachother as they dug against a database. The whole thing is
woefully out of date at this point, and platform-dependant, so we needed to
switch to something.. and Python won. Yay.
    In the new platform, we'll be building a distributed system with CORBA
(omniORB + omniORBpy, etc) with Python making up most of our development for
the new edition of our software. Woohoo. Much fun.

    My question is not 'how suitable is Python for large projects?', but
instead more, 'Do you have any advice for large projects with Python?'.

    For example, our system will be made up of numerous applications -- 
three or four 'servers', multiple clients, all talking to eachother, sharing
a great deal of code. Any suggestions for organization? Our current plan is
to put everything under the 'site-packages' tree of a Python installation we
provide/control, with a fairly deeply nested tree:

        apt
        apt\library
        apt\library\corba.py
        apt\library\database\*
        apt\library\controls\*
        apt\application\globalapp1\
        apt\application\globalapp2\
        apt\system\editorial\application\client\
        apt\system\editorial\application\client2\
        apt\system\editorial\library\elementgrid.py

... etc. You get the idea, I hope. We have apt.library where we store all of
our 'global', 'shared' libraries that everything can make use of, and
apt.application with some global, shared apps. Then we have 'systems', which
are a collection of applications and libraries in a single domain. These
mostly get sold as a single product, really. Etc, etc.

    I end up doing a lot of:

        from apt.library.corba import *
        from apt.library.database import Connection
        from apt.library import machine
        from apt.system.editorial.library.elementgrid import ElementGrid

    ... And such. When PEP328 gets in, this may become more attractive, but
occasionally I'm alarmed by the depth of the whole thing. But I also want to
keep stuff logical and separated.

    And how about distribution? Freezing and such won't work, because of the
shared nature of most of this code. Currently I'm probably planning on
looking into finding the build scripts for python, win32all, and wxPython
and seeing if I can combine them into one single install. Don't know if
that's the best thing to do or not, but expecting my customers to install
this stuff... is expecting too much of them.

    For example: Traditionally my company has avoided installing software on
a users local machine. Instead we install to a file server and have everyone
run the software from there. A bit of a performance hit but the advantage of
administration is very important, because our customers do not necessarily
have a very strong IT staff. There is some concern that if we do this same
thing with Python, the performance hit of loading an interpreted environment
over the shared filesystem will be prohibitive. Some basic testing has made
this seem to be the case.

hmm. That's all I have for now. I think. :)

Thanks in advance.

--Stephen