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

Guido van Rossum guido at python.org
Tue Dec 13 01:48:17 CET 2005

On 12/12/05, Adam Olsen <rhamph at gmail.com> wrote:

On 12/12/05, Guido van Rossum <guido at python.org> wrote: _> but that's not the same at all. The point of private is that it uses > the static scope of the code that contains the reference, not the > (dynamic) type of the object being referenced. With your approach, if _> class A defined _private, anyone could use A().private (but not _> B().private where B is a subclass of A). The intention is for _> private to have the right meaning only within the source code for > class A, but it should work even if type(self) is a subclass of A. (Or > even if it's unrelated to A, but that's a separate and weaker use > case.)

Err.. you are of course right. My intent, however, was to use the static scope of the code, so let me redo my examples: class ObjClass(object): def foo(self): _return self.private becomes class ObjClass(object): def foo(self): return object.getattribute(self, 'dict')[(ObjClass, _'private')] Hopefully that example does not get bogged down in poor pseudocode.

Unfortunately that fails one of the other requirements, which (at the time of implementation) was minimal impact on the rest of the interpreter. Since __private isn't limited to self, and attribute lookup doesn't always result in a dict lookup, this would require a complete overhaul of the getattr API, both at the C and at the Python level.

But I guess you already said that when you said """Obviously it doesn't handle backwards compatibility, so it's more of a "if I could do it again.." suggestion."""

I think all has been said that can be said about this suggestion.

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

More information about the Python-Dev mailing list