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/058614.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:17:17 CET 2005
On 12/12/05, Jim Fulton <jim at zope.com> wrote:
> In practice, I don't agree that it works fine.  Inevitably, someone
> finds a need to access a "private" variable in a subclass.  Or
> even in the original class, you find some need to use something like
> __getattr__ where the implicit name mangling doesn't come into play
> and you have to emulate the name mangling.  Or perhaps someone wants
> to examine the value of one of these variables in the debugger.
> In my experience, almost every time someone uses the __private
> trick, they or someone else comes to regret it.
>
> OTOH, explicit name mangling provides the benefits of implicit
> name mangling without it's drawbacks.

I half agree. I've seen many classes overuse __private. But that's a
separate issue from not having the feature at all; you might as well
argue against private in Java or C++.

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