On 12/12/05, Scott David Daniels <[EMAIL PROTECTED]> wrote: > Jim Fulton wrote: > > Ian Bicking wrote: > >> Jim Fulton wrote: > >>> Ian Bicking wrote: > >>>> Private attributes should have two leading underscores, no > >>>> trailing underscores. > >>>> > >>>> This conflicts with a previous suggestion "Generally, double leading > >>>> underscores should be used only to avoid name conflicts with > >>>> attributes in classes designed to be subclassed." Or perhaps > >>>> "private attributes" needs to be better explained. > ... > >> I really really hate double underscores, but I thought I'd let some > >> other people suggest stronger language first.... > > > > Can we officially mark __private as a mistake. Perhaps: > > - Strongly discourage it in the style guide > > - Mark it in the language reference as a deprecated feature > > - Generate deprecation warnings when it is used? > > (This might be too much.) > > Perhaps "The __ name convention is designed for 'mixins'; as a means of > enforcing "private" it is both ineffective and annoying. For example, > distutils.msvccompiler uses a bunch of instance variables which would I > would like to access in a subclass, but are "unavailable" because the > author could not imagine why I would need them.
These are really separate issues, right? The effect of __ names is to make a variable private to a class, because it's a right pain to access it from any other class. If you design a class for inheritance and use __ names, you're deciding to keep the details of those names private. There is a separate question about whether the designer of msvccompiler made the right choices about which instance variables were private. This issue is really separate from the naming mechanism. If the designer of the class didn't intent to make those instance variables available to you, it's not the language's fault. There are ways the language and tools could make things easier for developers. The debugger could know how to mangle names for us. It would be great to have editors/ides that could rename all the variables if we decide to change the name to make it available to subclasses. I think these problems are the primary reasons I dislike mangled names. I can't remember how to type the names in pdb and it's a pain to change every use of the name if I change from __var to _var. C++ private variables don't suffer from either of these problems. The visibility is separate from the name; if I change an instance variable from private to protected, I don't have to edit existing code to track a new name. Jeremy _______________________________________________ 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
