Python for Large Projects

[David Fraser]

Ixokai wrote:
> 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.
Well you don't neccessarily have to have everything under apt... You 
just need to have unique package names.
Also the cleaner your system design the less you should have to refer to 
bits inside other packages.
> 
>     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.

On the wxPython users list we are planning something called wxPRE which 
would be an environment pre-setup with Python and wxPython. You may want 
to help set this up as it is very similar to your requirements.
See http://wiki.wxpython.org/index.cgi/wxPRE

David