Re: [Tutor] style question: when to "hide" variable, modules
Kent Johnson wrote: The reason that is given for using accessors is that it gives you a layer of flexibility; if you want to change the representation of the data, or make it a computed attribute, you can do that without impacting clients. Python, instead, lets you change what attribute access means. The way to do this is with 'properties'. This is kind of an advanced topic, here are two references: http://www.python.org/2.2.1/descrintro.html#property http://www.python.org/doc/2.2.3/whatsnew/sect-rellinks.html#SECTION00034 Here is a blog entry that clearly explains the difference between Java and Python on this point. It also has a great explanation of why Python IDEs are not as popular as Java IDEs. http://naeblis.cx/rtomayko/2005/01/20/getters-setters-fuxors Kent ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] style question: when to "hide" variable, modules
On Jan 18, 2005, at 22:50, Kent Johnson wrote: Python, instead, lets you change what attribute access means. The way to do this is with 'properties'. This is kind of an advanced topic, here are two references: http://www.python.org/2.2.1/descrintro.html#property http://www.python.org/doc/2.2.3/whatsnew/sect- rellinks.html#SECTION00034 I have to admit, this is brilliant. Thanks for the pointer, Kent. -- Max maxnoel_fr at yahoo dot fr -- ICQ #85274019 "Look at you hacker... A pathetic creature of meat and bone, panting and sweating as you run through my corridors... How can you challenge a perfect, immortal machine?" ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] style question: when to "hide" variable, modules
Paul Tremblay wrote: On Fri, Jan 14, 2005 at 08:11:32PM -0500, Kent Johnson wrote: - 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? Well, in Java and C++ programming that is what I was taught. Python culture is different and it seems to work OK. class Backup: __init__(self): self.some_var = 5 burn_obj = Burn(self) class Burn: __init__(self, main): setattr(main, 'some_var', 6) main.some_var = 6 will work just fine. The reason that is given for using accessors is that it gives you a layer of flexibility; if you want to change the representation of the data, or make it a computed attribute, you can do that without impacting clients. Python, instead, lets you change what attribute access means. The way to do this is with 'properties'. This is kind of an advanced topic, here are two references: http://www.python.org/2.2.1/descrintro.html#property http://www.python.org/doc/2.2.3/whatsnew/sect-rellinks.html#SECTION00034 ??? - 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. It's in the standard library - /lib/optparse.py Kent 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 ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] style question: when to "hide" variable, modules
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_
Re: [Tutor] style question: when to "hide" variable, modules
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
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.
- 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
Re: [Tutor] style question: when to "hide" variable, modules
> My question is, how far should one take these guidlines? My response is, as far as you need and no further. In other words if it would actually cause problems for clients to access those variables disguise them, but otherwise trust your fellow programmers not to be stupid. Its the same principle as the recent discussion about private/public keywords etc. Comments and docstrings can help too. Alan G. ___ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
[Tutor] style question: when to "hide" variable, modules
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
