Globals or objects? (is: module as singleton)

[James Newton]

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