On Thu, May 6, 2021 at 10:16 AM Shreyan Avigyan <pythonshreyan09@gmail.com> wrote:
Most of the time when someone fixes a bug using a private member of another class then it's completely considered private code. Sometimes applications can cause crashes if there's memory leak or modification. Like there's an example where you change the name attribute of a bank account class and then there's a new account file created with that name when we never created or told to create that account file. And as I suggested,

> The main aim of private is to avoid modifying not accessing.

As everyone knows, in Python we use a single underscore as a signal to other programmers that they should exercise caution if they want to  make use of it, and a double underscore (compounded by name-mangling, which I refer to as hyper-private) for an even stronger signal.  However, it is part of Python's philosophy to treat programmers as "consenting adults" who can assume risk when warranted. In many of my projects, I have found it desirable to modify some "private" method as the public API is preventing me from achieving a given goal. As an example, see https://github.com/aroberge/friendly/blob/b7be071daaace87dab4aba540f14b9c222076dc7/friendly/theme/friendly_rich.py#L36  (and L45) where I patch two hyper-private methods of the excellent Rich library to "fix" a limitation of the original API.  I absolutely love the fact that I can do this when using Python. I suspect that I am not the only one.

Huge -1 for the idea of introducing truly private variables or methods in Python.

André Roberge


 
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3KI7I4GQSVWLEJ2M2FOGWLEHIQHKM2N5/
Code of Conduct: http://python.org/psf/codeofconduct/