__mangled in stdlib considered poor form
I'd like to see all occurrances of __mangledName in the stdlib removed and replaced with just _mangledName. Rationale: The double-under "private" names are a hack. They don't really protect variables, except against accidental stomping by subclasses. Looking at the uses in the std lib, they're not being used for that - they're being used for internal details. A single underscore is sufficient for that. The mangled names cause problems when someone _needs_ to override the implementation details in a subclass - I can recall a case with ConfigParser in SpamBayes, where the end result was the subclass with code like __ConfigParser_foo (a subsequent release of Python fixed that instance of double-under madness). Yes, you shouldn't be fiddling with internals of a class in a base class, and any time you do this, you run the risk of being refactored into oblivion, but sometimes it's necessary. Double-under mangled names are the worst of both worlds - they don't actually protect the variables, but they force someone who needs to poke into the class to use a mangled name. Given that part of the purpose of the stdlib is to act as a sort of "best practice" example of Python code, I'd like to see all instances of it in the std library removed. I'm not sure if it's feasible to attack this before 2.4b1, or if it should wait until 2.5, but I _would_ like to see it happen. What sayeth the rest of python-dev? Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Anthony Baxter <anthony@interlink.com.au> writes:
I'd like to see all occurrances of __mangledName in the stdlib removed and replaced with just _mangledName.
[...]
What sayeth the rest of python-dev?
+1. Make sure you get unittest.py too. Cheers, mwh -- <MFen> want to write my requirements for me? <radix> Sure! <radix> "show a dancing monkey in the about box" -- from Twisted.Quotes
I'd like to see all occurrances of __mangledName in the stdlib removed and replaced with just _mangledName.
[...]
What sayeth the rest of python-dev?
+1.
+0.5 here. Let's first get the terminology straight: __foo is a private name, _Class__foo is the mangled form of that. Whenever the stdlib uses a mangled name, clearly what ought to be done is change the private name to a single underscore. (I don't want to call that protected, because that has a different meaning in Java etc.) There's one potential use case where I'd like to keep the private name even if there's a mangled use of it nearby: when the private name really is intended to be private, and the mangled use is a "friend" in the C++ sense. Sometimes (though rarely) the stdlib has to indulge in practices that aren't good example code, because it's the stdlib, and it should implement functionality in the most bulletproof way possible. Using private names for internal details is the right thing sometimes. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Sat, 2004-08-28 at 14:50, Guido van Rossum wrote:
There's one potential use case where I'd like to keep the private name even if there's a mangled use of it nearby: when the private name really is intended to be private, and the mangled use is a "friend" in the C++ sense. Sometimes (though rarely) the stdlib has to indulge in practices that aren't good example code, because it's the stdlib, and it should implement functionality in the most bulletproof way possible. Using private names for internal details is the right thing sometimes.
Please don't just mindlessly change all leading double underscores to singles. +1, when following Guido's guidelines above though. -Barry
participants (4)
-
Anthony Baxter -
Barry Warsaw -
Guido van Rossum -
Michael Hudson