Mel wrote: >> James Newton wrote: >> Could you give a bare-bones demonstration of [implementing a singleton >> by using a module]? > > I had a club-membership application that ran for several years. > Default pathnames, etc. for the particular year came from a module > called thisyear.py: > #========================= > '''Values used to access this years trakkers files. > $Id: thisyear.py,v 1.2 2006/08/26 16:30:23 mwilson Exp $ > ''' > > memberpath = '2006-7/20062007.txt' # path to this years membership CSV > dirname = '2006-7' # directory name for this year > #========================= > Programs that needed to use the comma-separated-value membership base > would import thisyear, and pass thisyear.memberpath when creating the > CSV reader object. Etc.
Hi Mel, So you were using thisyear.py as a preferences file: making it a module was a shortcut for reading in the file and parsing its contents. I like it. Would there be any circumstances where the singleton module would include functions and objects? In particular, would this system work if the application needed to change a value (such as a counter)? Suppose your application wanted to save the changed value, so that the next session started using the new value. Could you simply write out a new copy of the thisyear.py file? Or would this lead to version issues? Would a previously-imported version of the module be stored in a different place in RAM than a module that was imported after the change was made? Perhaps my real question is about how to visualize a module: what makes an imported module different from an instance? Thanks for your insights, James -- http://mail.python.org/mailman/listinfo/python-list