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/058568.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 04:58:25 CET 2005
On 12/11/05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> Keeping it for Py3K would be fine, if the mechanism was changed so that it
> actually worked right. That is, the mechanics would be such that any two
> concurrently existing classes would be guaranteed to mangle the names of their
> private variables differently - simply using the class name (as now) doesn't
> guarantee that when inheriting from a class in a different module and reusing
> the name.

I know about the fear of accidental reuse of class names, but I don't
find it a compelling argument. Python encourages shallow class
hierarchies. It's easy to find all the base classes (look at __mro__).
It's unlikely that a hierarchy refactoring will introduce a new name
conflict after the fact.

Also, I like the current, well-defined mangling algorithm; it means
that when I'm in the debugger I can manually mangle or unmangle names
as required.

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