[Python-Dev] PEP 8 updates/clarifications

[Ian Bicking]

Raymond Hettinger wrote:
>>Do not use accessor methods, like ``obj.getFoo()`` and
>>``obj.setFoo(v)``, instead just expose a public attribute
> 
> (``obj.foo``).
> 
> This advice is, of course, not appropriate for all users (properties are
> not typically in a Python beginner's skill set) or all use cases.  It is
> closer to one person's view of the One-Right-Way(tm).  Opinions on
> programming best practices vary widely, evolve over time, and may be
> context dependent.

Beginning programmers do all sorts of things that aren't considered good 
style by more experienced programmers.  That's fine -- but then PEP 8 
should direct them to a better style.  Specifically PEP 8 currently 
suggests that public attributes should be avoided, and this no longer 
needs to be the case.  But at the same time, people are using Java 
conventions of setters and getters (and these conventions exist in older 
code as well), so I think it is helpful to suggest that accessor methods 
should be avoided.  I don't think the suggestion has to be strongly worded.

>>>While, on some level, private variables seem attractive, I think that
>>>experience (for everyone I know) has shown them to be an attractive
>>>nuisance.  I recommend discouraging them.
>>
>>I really really hate double underscores
> 
> 
> FWIW, I think we have no business dictating to others how they should
> name their variables.  This is doubly true for a convention that has a
> long history and built-in language support.

Double underscores aren't just naming, they involve the semantics of 
name mangling.  That's what makes them different than other names, and 
jarring to many programmers (like myself).

Personally I'm happy if we call double underscore attributes "hidden" 
instead of "private", or otherwise help keep people from being 
misdirected into using double underscore as "real" private variables. 
PEP 8 currently gives the impression that they should be used for 
private attributes.

> My preference is to leave PEP 8 for the minimum practices necessary for
> one programmer to be able to read and maintain another programmer's
> code.

There's a couple things I want to use PEP 8 for:

* Deciding on things I don't care that much about, except in terms of 
consistency.  I am happy that PEP 8 was updated to say that underscore 
separated words are preferred, for instance, though I would have been 
just as happy with mixed case.  I just want everyone to at least move 
towards being on the same page.

* When debates on these styles come up, I want to be able to point to 
something somewhat authoritative.  This avoids a lot of pointless 
discussion.

Given these motivations, I guess I don't care that much about how __ is 
presented in PEP 8, except that the current inconsistent messages about 
it is made consistent, and that it isn't misrepresented as being the way 
of indicating "private".  I don't think PEP 8 needs to be a text on good 
API design.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org