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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com