[Tutor] style question: when to "hide" variable, modules
Jacob S.
keridee at jayco.net
Sat Jan 15 16:07:24 CET 2005
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
>
>
More information about the Tutor
mailing list