RetroSearch Browse

Tue Dec 13 01:24:33 CET 2005 · https://mail.python.org/pipermail/python-dev/2005-December/058640.html

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.

--
Adam Olsen, aka Rhamphoryncus

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2005-December/058640.html below:

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