A RetroSearch Logo

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

Search Query:

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

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

[Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications) [Python-Dev] Deprecate __ private (was Re: PEP 8 updates/clarifications)Guido van Rossum guido at python.org
Mon Dec 12 20:15:06 CET 2005
On 12/12/05, Adam Olsen <rhamph at gmail.com> wrote:
> When I need an identifier unique to a class I just use a reference to
> the class itself.  As such I'd like to suggest that
> obj.__private
> be converted to
> obj.__dict__[(type(obj), '__private')]
>
> Note that I'm accessing __dict__ directly so as to avoid getattr's
> requirement for attribute names to be strings.
>
> Obviously it doesn't handle backwards compatibility, so it's more of a
> "if I could do it again.." suggestion.

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

--
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4