python development practices?

[Cliff Wells]

On Wednesday 31 October 2001 10:57, James_Althoff at i2.com wrote:
> I know I'm in the minority on this, but I greatly dislike the _iamspecial
> naming convention.  To me, it's unnecessary and ugly clutter -- especially
> when I see classes with 80% or 90% of the fields and methods named with a
> leading  _.   In which case practically every line of code is slathered in
> clutter.  Not to mention the fact that mangling-based hiding only happens
> with a *double* (not single) leading underscore naming convention -- how
> ugly does *that* make the code.  The rule in my projects, rather, is thus:
> *all* instance variables are non-public -- following the "keep it simple"
> principle.  If you are debugging things or are just exploring using the
> interpreter then, by all means, have at them (and I think it is very useful
> that you can do this in Python).  But if you are writing (non-ephemeral)
> code outside of the defining class (or subclasses), then please use the
> provided get/set methods.  If no such get/set methods exist there should be
> no mystery about the intent of the fields.  Publicly-intended methods are
> annotated with "Public" at the start of their doc strings.  Anything
> without such annotation -- please use only for debugging or exploring
> (again, outside of the defining class or subclasses).

I tend to use this method as well.  My feeling is that keeping data 
attributes private (by convention) helps keep classes as "black boxes".  This 
allows the internal implementation of the class to change at will as long as 
the get/set methods provide the same interface.  This allows things such as 
changing a list to a dictionary without fear that this will break some 
outside code.

-- 
Cliff Wells
Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308
(800) 735-0555 x308