[Python-Dev] PEP 8 updates/clarifications

Jim Fulton jim at zope.com
Tue Dec 13 13:14:14 CET 2005


skip at pobox.com wrote:
>     Jim> I don't understand this argument.  Any mutating method or property
>     Jim> invoked by foreign code changes an object's state.  
> 
> Sure, but the only place I need to look for direct changes to the object's
> state are in the object's own code.
 >
>     Jim> If you provide a property or a pair if accessors that just sets and
>     Jim> gets an attribute with a slightly different name, that affords no
>     Jim> more protection than if people were setting the attribute directly.
> 
> Sure it does.  Suppose I get an exception in my code because some bit of
> code somewhere broke my assumptions about the values an attribute could
> assume.  If that attribute is only set by the object's own code, I can more
> easily debug it (stick in a print or an assert in the places where the
> attribute changes, etc).  If some external bit of code does something like
> 
>     self.foo = Foo()
>     ...
>     self.foo.attr = None
> 
> then later in Foo's code I have something like
> 
>     self.attr.callme()
> 
> The first thing I need to do is figure out who stomped on self.attr.  That
> can be time-consuming if I don't necessarily know where the stomping
> occurred.

I just don't buy this argument. For trivial accessors and properties,
you can't just look at your code to know where the changes are initiated.
For debugging purposes, it's easy to add a property to allow debugging
of attribute assignment.

> At work we use Python for very rapid development of trading applications.
> Today I think we made about a half-dozen micro releases fixing bugs and our
> traders tried each one immediately live.  Much of the design is carried
> around in our heads or consists of a few equations scribbled on sheets of
> paper.  As you might imagine, it's a very lively environment.  Localizing
> attribute modifications is a very good thing for us, even if they are simply
> one-line set methods.

Having to write accessors for all your public methods doesn't seem consistent
with rapid development.  It increases the ceremony of development and adds
lots of meaningless boilerplate that readers of the code have to wade through.
Note that they can't just skip over it, because they can't know if you've slipped
something meaningful into one of these accessors.

>     Jim> If you don't want external code to change an attribute, don't
>     Jim> expose it through a public API.
> 
> I suppose "public" is subject to some interpretation.  Just because I don't
> prefix an attribute with an underscore doesn't mean I've implicitly declared
> it public.  I assume that people will familiarize themselves with the
> callable methods of an object and only use direct attribute access if I
> haven't provided the necessary methods.

A better approach is to document the API for your classes and expect
people to use that API.  Prepending an underscore documents that a
variable or method is internal.  (Of course, there's still the subclassing
API to deal with, if you need one, but that's a separate issue.)

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org


More information about the Python-Dev mailing list