On 12/12/05, Guido van Rossum <[EMAIL PROTECTED]> 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
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
