[Tutor] style question: when to "hide" variable, modules

[Jacob S.]

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 at python.org
> http://mail.python.org/mailman/listinfo/tutor
> 
>