breaking up is hard to do

Larry Bates lbates at syscononline.com
Fri Mar 25 23:30:53 CET 2005


Kind of vague, but I'll give it a shot:

1) Don't read config.ini values in main and pass to class if they
aren't needed in the main program.  Instead create instance of
ConfigParser and pass it as an argument to the class and extract
the individual section/option information in the class.

INI=ConfigParser.ConfigParser()
INI.read(inifilename)

b=newclass(INI)

then in newclass you just get what you want from the .INI file.
You aren't actually reading from the file, the read put it in
a dictionary.

2) Pump variables into dictionary and pass it as **kwargs argument
to functions/classes.

Example:

class foo:
    def __init__(self, **kwargs):
        self.trace=kwargs.get('trace',0)
        self.debug=kwargs.get('debug',0)
        self.outputfile=kwargs.get('outputfile', 'out.txt')
        .
        .
        .


global_dict={'trace': 0, 'debuglevel': 2, 'outputfile': 'outfile.txt'}

F=foo(**global_dict)

Then if your nesting goes deeper, just pass **kwargs to functions or
classes that are lower down.

Hope this helps.

Larry Bates


bbands wrote:
> I've a 2,000 line and growing Python script that I'd like to break up
> into a modules--one class alone is currently over 500 lines. There is a
> large config.ini file involved (via ConfigParser), a fair number of
> passed and global variables as well as interaction with external
> programs such as MySQL (via MySQLdb), R (via Rpy) and gnuplot (via
> Gnuplot). Every time I have tried to break it up I end up with thorny
> name-space problems and have had to stitch it back together gain. Any
> pointers to materials on how best to modularize a script such as this
> would be appreciated. I'd like to end up with most of the code in
> modules and with just the main logic and housekeeping stuff in the main
> module.
> 
> John
> 
> PS The script works fine as is and I am a very happy and productive
> camper with Python. I was a BASIC user for many years who switched to
> Python a year and a half ago rather than moving to .NET.
> 



More information about the Python-list mailing list