This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: protected members accessible in other modules
Type: behavior Stage: resolved
Components: Versions: Python 3.9
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Dennis Sweeney, niharranjanroy
Priority: normal Keywords:

Created on 2021-05-27 04:37 by niharranjanroy, last changed 2022-04-11 14:59 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
Screenshot (108).png niharranjanroy, 2021-05-27 04:37
Messages (5)
msg394509 - (view) Author: Nihar Ranjan Roy (niharranjanroy) Date: 2021-05-27 04:37
As per literature protected members are not accessible in other modules but I found that there is no difference between public and protected members in python 3.9.0
msg394510 - (view) Author: Dennis Sweeney (Dennis Sweeney) * (Python committer) Date: 2021-05-27 05:04
Being in different modules is irrelevant. Attribute names that start with double underscores and don't end with double underscores are "mangled" by the compiler to include the class name as well:

>>> class MyClass:
...     def __init__(self):
...         self.__data = 17
... 
...         
>>> x = MyClass()
>>> x._MyClass__data
17


See https://docs.python.org/3/tutorial/classes.html?highlight=mangle#private-variables

I don't think there's a bug here.
msg394511 - (view) Author: Nihar Ranjan Roy (niharranjanroy) Date: 2021-05-27 05:11
Dear Dennis
Thanx for the prompt reply.
I am talking about protected members (those starting with single
underscore). Take it other way, What is the difference between public and
private membership in python?

With Regards
Nihar Ranjan Roy
Mobile: +91 9810 977 908
___________________

On Thu, May 27, 2021 at 10:34 AM Dennis Sweeney <report@bugs.python.org>
wrote:

>
> Dennis Sweeney <sweeney.dennis650@gmail.com> added the comment:
>
> Being in different modules is irrelevant. Attribute names that start with
> double underscores and don't end with double underscores are "mangled" by
> the compiler to include the class name as well:
>
> >>> class MyClass:
> ...     def __init__(self):
> ...         self.__data = 17
> ...
> ...
> >>> x = MyClass()
> >>> x._MyClass__data
> 17
>
>
> See
> https://docs.python.org/3/tutorial/classes.html?highlight=mangle#private-variables
>
> I don't think there's a bug here.
>
> ----------
> nosy: +Dennis Sweeney
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue44244>
> _______________________________________
>
msg394512 - (view) Author: Dennis Sweeney (Dennis Sweeney) * (Python committer) Date: 2021-05-27 05:17
An attribute name starting with a single underscore is just a warning to users of your code that "this attribute is supposed to be private, access it at your own risk."

Everything below is from https://docs.python.org/3/tutorial/classes.html?highlight=mangle#private-variables :

“Private” instance variables that cannot be accessed except from inside an object don’t exist in Python. However, there is a convention that is followed by most Python code: a name prefixed with an underscore (e.g. _spam) should be treated as a non-public part of the API (whether it is a function, a method or a data member). It should be considered an implementation detail and subject to change without notice.

Since there is a valid use-case for class-private members (namely to avoid name clashes of names with names defined by subclasses), there is limited support for such a mechanism, called name mangling. Any identifier of the form __spam (at least two leading underscores, at most one trailing underscore) is textually replaced with _classname__spam, where classname is the current class name with leading underscore(s) stripped. This mangling is done without regard to the syntactic position of the identifier, as long as it occurs within the definition of a class.

Name mangling is helpful for letting subclasses override methods without breaking intraclass method calls. For example:

...
msg394514 - (view) Author: Nihar Ranjan Roy (niharranjanroy) Date: 2021-05-27 06:33
Thank you dennis. This is helpful.

With Regards
Nihar Ranjan Roy
Mobile: +91 9810 977 908
___________________

On Thu, May 27, 2021 at 10:47 AM Dennis Sweeney <report@bugs.python.org>
wrote:

>
> Dennis Sweeney <sweeney.dennis650@gmail.com> added the comment:
>
> An attribute name starting with a single underscore is just a warning to
> users of your code that "this attribute is supposed to be private, access
> it at your own risk."
>
> Everything below is from
> https://docs.python.org/3/tutorial/classes.html?highlight=mangle#private-variables
> :
>
> “Private” instance variables that cannot be accessed except from inside an
> object don’t exist in Python. However, there is a convention that is
> followed by most Python code: a name prefixed with an underscore (e.g.
> _spam) should be treated as a non-public part of the API (whether it is a
> function, a method or a data member). It should be considered an
> implementation detail and subject to change without notice.
>
> Since there is a valid use-case for class-private members (namely to avoid
> name clashes of names with names defined by subclasses), there is limited
> support for such a mechanism, called name mangling. Any identifier of the
> form __spam (at least two leading underscores, at most one trailing
> underscore) is textually replaced with _classname__spam, where classname is
> the current class name with leading underscore(s) stripped. This mangling
> is done without regard to the syntactic position of the identifier, as long
> as it occurs within the definition of a class.
>
> Name mangling is helpful for letting subclasses override methods without
> breaking intraclass method calls. For example:
>
> ...
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue44244>
> _______________________________________
>
History
Date User Action Args
2022-04-11 14:59:46adminsetgithub: 88410
2021-05-27 06:33:17niharranjanroysetmessages: + msg394514
2021-05-27 05:32:08iritkatrielsetstatus: open -> closed
resolution: not a bug
stage: resolved
2021-05-27 05:17:19Dennis Sweeneysetmessages: + msg394512
2021-05-27 05:11:17niharranjanroysetmessages: + msg394511
2021-05-27 05:04:00Dennis Sweeneysetnosy: + Dennis Sweeney
messages: + msg394510
2021-05-27 04:37:34niharranjanroycreate