- you might want to make a configuration object that you can pass around, this is probably better than passing around an instance of the main Burn class.
- typical Python style is *not* to define setter and getter functions. If you need to mediate attribute access you can do it later using properties.
- you might want to consolidate your classes into a small number of modules. This is the style of much of the Python standard library. Look at optparse.py for an example (picked more-or-less at random).
- if one class has a helper class or function that isn't used anywhere else, put the helper into the same module as the client and name the helper starting with _.
- I tend to worry more about naming with _ in a module that is likely to be reused. For a module that will probably be only be used once, I don't use _ at all. In a module that has a public API I try to use _ to distinguish the implementation details from the public stuff.
HTH Kent
Paul Tremblay wrote:
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
