Thanks for your input (and others, too!).
On Fri, Jan 14, 2005 at 08:11:32PM -0500, Kent Johnson wrote:
> Date: Fri, 14 Jan 2005 20:11:32 -0500
> From: Kent Johnson <[EMAIL PROTECTED]>
> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
> Cc: tutor@python.org
> Subject: Re: [Tutor] style question: when to "hide" variable, modules
>
> A few thoughts:
> - 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.
I actually pass around many instances. Maybe this is bad programming,
but I can't think of a better way to share attributes across modules.
For example, one class splits lists. I want both my message class and my
burn class to have access to the current state of the split list.
> - 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.
I treid to figure out how this works with no luck. It seems that when
you use property, you don't necessarily update the attribute. It seems I
want the setattr() and getattr() functions? I always thought it was bad
programming to alter an attribute directly in OO programming, but it
seems I am mistaken?
class Backup:
__init__(self):
self.some_var = 5
burn_obj = Burn(self)
class Burn:
__init__(self, main):
setattr(main, 'some_var', 6)
???
> - 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).
I couldn't find the optparse.py module. But looking at other packages
and modules, it seems that the one module shouldn't run more than 500
lines. I * could* consolidate many of my classes in one file, but that
would make very long files.
Thanks
Paul
> - 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
--
************************
*Paul Tremblay *
[EMAIL PROTECTED]
************************
_______________________________________________
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
