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

[Guido van Rossum]

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