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

Guido van Rossum guido at python.org
Mon Dec 12 20:11:42 CET 2005

On 12/11/05, Steven Bethard <steven.bethard at gmail.com> wrote:

On 12/11/05, Guido van Rossum <guido at python.org> wrote: > I know about the fear of accidental reuse of class names, but I don't > find it a compelling argument.

FWIW, I know I currently have a number of classes that are potentially hazardous in this way. Each of these classes is basically a substitute class for a third-party API that I have to code to. The API is missing a number of convenience methods, and the most straightforward way to introduce these methods[1] is to create a subclass of the appropriate class. Since they are in a different module, it seems perfectly normal for me to give them the same name since for all external modules, they should look the same as the original API (but with the added methods). So I have a number of classes that look something like: class Document(cdm.Document): ... # add convenience methods here ...

Personally, I find that naming convention a mistake. Call it MyDocument or EnhancedDocument or DocumentPlusPlus (be creative!) but don't reuse the original name.

I'm not saying this because it helps the __private argument; I'm saying this because in lots of contexts we leave out the package/module path and only use the class name, and added functionality is a good reason to be able to distinguish between the original class and the enhanced version.

> Also, I like the current, well-defined mangling algorithm; it means > that when I'm in the debugger I can manually mangle or unmangle names > as required.

Why couldn't the name mangling do something like: '%s%s%s' % (cls.module, cls.name, attrname)_

Too long, IMO.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list