Mailing List Archive

Designing questions
I'm writing a application wich contains abouth 50 inputscreen linked to
db-tables.
Each inputscreen has 2 classes
- 1 GUI class wich construct the screen.
- 1 db class wich do the db acces.

All the gui-classes are done at the moment, so i have the prototype of
the application.
And here's my problem :
The source code becomes realy long, wich gives a long time to load it. I
was thinking of spliting it in modules (1 module for each screen wich
contains the gui-class and the db-class) and then importing it when i
needed it, this is when the user makes the choice in the main-menu.
The question i have is how to 'unload' a module when i don't need it
anymore ? If i don't unload a module i would have as many modules in
memory as the user has made choises in the main menu.
I think this could become a memory problem especailly since i'm using
gadfly as db, wich allso holds the tables in memory.

I really would appreciate some hints and comments here from experienced
guys who allready wrote BIG real world applications in PYTHON.

Pierrette
A kiss from a french lady for every answer :)

If possible send a copy of your answer to my e-mail bucodi@worldnet.fr
Designing questions [ In reply to ]
Pierrette writes:

> I'm writing a application wich contains abouth 50 inputscreen
> linked to db-tables. Each inputscreen has 2 classes - 1 GUI class
> wich construct the screen. - 1 db class wich do the db acces.

I remember you!

> All the gui-classes are done at the moment, so i have the prototype
> of the application. And here's my problem : The source code becomes
> realy long, wich gives a long time to load it. I was thinking of
> spliting it in modules (1 module for each screen wich contains the
> gui-class and the db-class) and then importing it when i needed it,
> this is when the user makes the choice in the main-menu. The
> question i have is how to 'unload' a module when i don't need it
> anymore ? If i don't unload a module i would have as many modules
> in memory as the user has made choises in the main menu. I think
> this could become a memory problem especailly since i'm using gadfly
> as db, wich allso holds the tables in memory.

Well, you don't unload modules in general, and I bet it won't be a
problem. You will gain a lot of speed, because for imported modules,
Python will create a .pyc the first time it's imported, and use that
(if the .py file hasn't changed) on subsequent imports.

In other words, one way to speed up loading is to create a very small
main script:
-----------------------------
import myrealstuff
myrealstuff.run()
-----------------------------

This script will be interpreted each time, but "myrealstuff" will get
pre-compiled.

Breaking up your script is a good idea for maintainability, too. But
rather than just chop it in pieces, I'd look carefully to see if all
those GUI classes don't have some things in common that can be
factored into a base class. Then each GUI class can inherit from
that, and just add the stuff that's particular to that screen.

You could use the same idea on the db classes, too, but I'd guess
that most of your code is GUI code. With gadfly, make sure you use
the form of SQL that uses "?"s to mark the variables. That will let
gadfly precompile the SQL statements.

> I really would appreciate some hints and comments here from
> experienced guys who allready wrote BIG real world applications in
> PYTHON.

That's me. Big guy, big Python <2.0 wink>

- Gordon