I'm not too sure about this... Couldn't you make that a package? Rename Backup.py to __init__.py Put all of the modules in a folder named Backup in your sys.path - Question: Does it have to be in site-packages?
Well, there's my two bits, Jacob > During the recent discussion on jython, a poster > brought up the good point that one should hide > variables and modules to indicate that they are > not for public use: > > self.__for_internal_purposes = 5 > > __internal_stuff.py > """ > This module only makes sense for use with > the parent module. > """ > > So one could write several modules using these > guidelines. One could then issue the command > from a shell pydoc internal_stuff, and sure enough, > one gets a nice listing of all the methods with the > __methods listed first, signalling to someone who > hasn't written the program (or to the author who > returns to it a few years later), that one shouldn't > look at these methods when looking what is useful > from the script. > > My question is, how far should one take these guidlines? > > I am working on an OO script with several modules that > backs up a hardrive. There will be about 10 modules, but > really only *one* of them, called backup, would be used > as a pubilc interface. Should I name the rest of them things > like __handle_archive.py, __file_system.py, and so on? That > seems odd, since I have never seen this done before. However, > it does have an elegance of clearly telling someone how to > hook into the modules. > > Also, maybe more importantly, I want to know how to handle > attributes that need to be shared. Imagine that there are around > 20 attributes, such as the level the program runs at, and the number > of the disk being copied that need to be shared with different > modules. Right now, my setup looks like this: > > # this module is called backup.py > > class Backup: > > __init__(self, verbose, level ): > self.__make_objects() > self.verbose = verbose > self.level = level > > > def __make_objects(self): > self.burn_obj = paxbac.burn.Burn(self) > self.archive_obj = paxbac.archive.Archive(self) > > def get_disk(self): > return self.__disk > > def set_disk(self, the_num): > self.__disk = the_num > > def backup(self): > archive_obj.archive() > burn_obj.burn() > > ***** > > #this is aother module called burn.py > > class Burn: > def __init__(self, main): > self.__main = main > > def burn(self): > cd_num = self.main.get_disk() > if self__main.level > 3: > sys.stdout.write('Burning disk %s\n' %cd_num) > > **** > > The main module backukp provides a number of public > methods that are really not public. For examle, no > one is going to want to use this module to find > out what disk the method is on. If I wanted to > be very strict with public and private variables > and methods, I would have to: > > 1. change burn.py to __burn.py > > 2. create a module called __attributes.py, create an > object in burn.py called self.__attributes_obj, and pass > this object to each method. > > These two steps seem to take things a bit far. On the other > hand, one could look at the set of modules and immediately > know how to use them. > > Thanks > > Paul > > > _______________________________________________ > Tutor maillist - Tutor@python.org > http://mail.python.org/mailman/listinfo/tutor > > _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor