PEP Idea: Real private attribute

[Calvin Spealman]

On Tue, Aug 31, 2021 at 1:19 PM Mehrzad Saremi <mehrzad.1024 at gmail.com>
wrote:

> Calvin, even if the language offered truly private members?
>

I'm saying I don't think they're necessary, especially not for the use case
posited here. Private members in other languages are about things internal
to the class of the object itself. If we *did* have them in Python, you
couldn't use private members of an object from a decorator on it because
the decorator is external to the target class.


> On Tue, 31 Aug 2021 at 17:31, Calvin Spealman <cspealma at redhat.com> wrote:
>
>> The right way for those decorators to hold some private information,
>> imho, isn't to put anything on the decorated object at all, but to use a
>> weak-ref dictionary using the target object as a key.
>>
>> On Sat, Aug 28, 2021 at 5:42 PM Mehrzad Saremi <mehrzad.1024 at gmail.com>
>> wrote:
>>
>>> Python currently uses name mangling for double-underscore attributes.
>>> Name
>>> mangling is not an ideal method to avoid name conflicting. There are
>>> various normal programming patterns that can simply cause name
>>> conflicting
>>> in double-underscore members. A typical example is when a class is
>>> re-decorated using the same decorator. The decorator can not take
>>> double-underscore members without name conflicts. For example:
>>>
>>> ```
>>> @custom_decorator("a")
>>> @custom_decorator("b")
>>> class C:
>>>     pass
>>> ```
>>>
>>> The `@custom_decorator` wrapper may need to hold private members, but
>>> Python's current name conflict resolution does not provide any solution
>>> and
>>> the decorator cannot hold private members without applying tricky
>>> programming methods.
>>>
>>> Another example is when a class inherits from a base class of the same
>>> name.
>>>
>>> ```
>>> class View:
>>>     """A class representing a view of an object; similar to
>>> numpy.ndarray.view"""
>>>     pass
>>>
>>> class Object:
>>>     class View(View):
>>>         """A view class costumized for objects of type Object"""
>>>         pass
>>> ```
>>>
>>> Again, in this example, class `Object.View` can't take double-underscore
>>> names without conflicting with `View`'s.
>>>
>>> My idea is to introduce real private members (by which I do not mean to
>>> be
>>> inaccessible from outside the class, but to be guaranteed not to conflict
>>> with other private members of the same object). These private members are
>>> started with triple underscores and are stored in a separate dictionary
>>> named `__privs__`. Unlike `__dict__` that takes 'str' keys, `__privs__`
>>> will be a double layer dictionary that takes 'type' keys in the first
>>> level, and 'str' keys in the second level.
>>>
>>> For example, assume that the user runs the following code:
>>> ```
>>> class C:
>>>     def __init__(self, value):
>>>         self.___member = value
>>>
>>> c = C("my value")
>>> ```
>>>
>>> On the last line, Python's attribute setter creates a new entry in the
>>> dictionary with key `C`, adds the value "my value" to a new entry with
>>> the
>>> key 'member'.
>>>
>>> The user can then retrieve `c.___member` by invoking the `__privs__`
>>> dictionary:
>>>
>>> ```
>>> print(c.__privs__[C]['member'])  # prints 'my value'
>>> ```
>>>
>>> Note that, unlike class names, class objects are unique and there will
>>> not
>>> be any conflicts. Python classes are hashable and can be dictionary keys.
>>> Personally, I do not see any disadvantage of using __privs__ over name
>>> mangling/double-underscores. While name mangling does not truly guarantee
>>> conflict resolution, __privs__ does.
>>>
>>> Please discuss the idea, let me know what you think about it, whether
>>> there
>>> are possible disadvantages, and if you think it will be approved as a
>>> PEP.
>>>
>>> Thanks,
>>> Mehrzad Saremi
>>>
>>> AI M.Sc. grad. from AUT
>>> --
>>> https://mail.python.org/mailman/listinfo/python-list
>>>
>>>
>>
>> --
>>
>> CALVIN SPEALMAN
>>
>> SENIOR QUALITY ENGINEER
>>
>> calvin.spealman at redhat.com  M: +1.336.210.5107
>> [image: https://red.ht/sig] <https://red.ht/sig>
>> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>>
>

-- 

CALVIN SPEALMAN

SENIOR QUALITY ENGINEER

calvin.spealman at redhat.com  M: +1.336.210.5107
[image: https://red.ht/sig] <https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>