Enhancement: Adding support for private and name mangled type hints in dataclasses module
I have a proposal for an addition to the dataclasses module that I think would make it easier to use private and name mangled variables. One of the benefits of the dataclass decorator is that it helps lessen the amount of code when you just need a simple constructor. A common pattern in python that isn't addressed by the current implementation is the pattern ```python class MyClass: def __init__(self, a: str, b: str): self._a = a self.__b = b ``` right now the only straightforward way of doing this with a dataclass is ```python @dataclass class MyClass: a: InitVar[str] b: InitVar[str] def __post_init__(self, a, b): self._a = a self.__b = b ``` My proposal would be to add two types to the dataclasses module, one called PrivateVar and one called MangledVar. These would add The above pattern (without the post_init ) using the syntax, ```python @dataclass class MyClass: a: PrivateVar[str] b: MangledVar[str] ``` I've already looked into what would need to be added to dataclasses to implement these and it's just a few lines of code since the class implementation would be very similar to InitVar. Is this something that other see the possibility of being added to python? (Also, I know name mangling isn't super common but I think it may as well be added alongside a private variable implementation))
A couple of thoughts: Does attrs have anything similar? Is this just a subset of a more general-purpose idea to have a different attribute name than the __init__ parameter name? What should repr show? The __init__ parameter name? Or the attribute name? I'd guess the __init__ parameter name. I'm not crazy about adding more uses of runtime type inspection, but I guess that ship has sailed with InitVar and ClassVar. Eric On 8/23/2020 5:36 PM, zachb1996--- via Python-ideas wrote:
While I agree that this is a subset of the idea of having a different attribute name, I think this naming convention is very common, and is even referenced in the python documentation. Which is why I think it would warrant being built in as opposed to using an InitVar. So the way attrs deals with private variables is actually even less ideal, because it pretends that the convention doesn't even exists since in python the variables aren't ever truly private, you can see that [here](https://www.attrs.org/en/stable/init.html#private-attributes). As for repr, I think it may actually be beneficial for these to be excluded, because if we're truly emulating private variables, a user shouldn't really know what they are without going into the code, although of course since it's python they could be fairly easily accessed through inspection and the dict attribute. Zach
A couple of thoughts: Does attrs have anything similar? Is this just a subset of a more general-purpose idea to have a different attribute name than the __init__ parameter name? What should repr show? The __init__ parameter name? Or the attribute name? I'd guess the __init__ parameter name. I'm not crazy about adding more uses of runtime type inspection, but I guess that ship has sailed with InitVar and ClassVar. Eric On 8/23/2020 5:36 PM, zachb1996--- via Python-ideas wrote:
While I agree that this is a subset of the idea of having a different attribute name, I think this naming convention is very common, and is even referenced in the python documentation. Which is why I think it would warrant being built in as opposed to using an InitVar. So the way attrs deals with private variables is actually even less ideal, because it pretends that the convention doesn't even exists since in python the variables aren't ever truly private, you can see that [here](https://www.attrs.org/en/stable/init.html#private-attributes). As for repr, I think it may actually be beneficial for these to be excluded, because if we're truly emulating private variables, a user shouldn't really know what they are without going into the code, although of course since it's python they could be fairly easily accessed through inspection and the dict attribute. Zach
participants (2)
-
Eric V. Smith -
zachb1996＠yahoo.com