[Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)

Jim Fulton jim at zope.com
Sun Dec 11 23:57:58 CET 2005


Ian Bicking wrote:
> Jim Fulton wrote:
> 
...
>>>        Also decide whether your attributes should be private or not.
>>>        The difference between private and non-public is that the former
>>>        will never be useful for a derived class, while the latter might
>>>        be.  Yes, you should design your classes with inheritence in
>>>        mind!
>>>
>>>        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.
>>
>>
>>
>> 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, but I thought I'd let some 
> other people suggest stronger language first.  I prefer explicit name 
> mangling for those cases where people justifiably use double underscores 
> now, e.g., self._MyPackage_variable instead of self.__variable, which I 
> think you also suggest below.  Since it's all name mangling anyway, at 
> least explicit is better than implicit, especially when it's something 
> one could argue *should* look a little ugly.  Perhaps all the 
> non-public/private language should be switched to just "private" (one 
> underscore) and "hidden from subclasses" (double underscore).  I don't 
> like calling __ private at all, because it's not what people coming from 
> other languages think of as private.

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.)

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