I like this idea. It will be useful if this would also rise ImportError if someone would like to import such object directly. I am not sure about naming convention, because maybe it could be attached to current convention for mangling (double “_”). If someone uses 2 underscores at the beginning, he would like to set it as “private” in most cases I suppose.
If Python will support that, it will raise also an exception if this object will be accessed directly and that is the most meaningful reason for me. One underscore is just indication, which does not throws any error.
As written, this seems to be useless, since there’s no useful way to construct a D without referencing the “internal” module. But if class C has a default too, then the most logical way to do this would be an inner class.
... class D:
... class __C:
... c: int = 0
... d: __C = field(default_factory=__C)
>>> x = D()
You can use normal double-underscore name mangling if you really need it, and everything works fine.
But more generally: Why do you actually need to hide this? What is insufficient about using a single underscore? Is it a problem that you make the module easier to unit-test?
The point of name mangling with double underscores in classes is not to hide things, but to avoid collisions with multiple inheritance. Because the name mangling algorithm is well known, nothing is really hidden.
Module level attributes do not have the same issue with name collisions, so there’s nothing to be gained by name mangling.
And in any event adding the proposed name mangling is a breaking change.
So there’s no reason to add mangling, and the specific proposal here won’t be accepted due to the breaking change.
As an illustration, we have a similar behavior in the Ren’Py engine : names beginnig with two underscores are mangled filename-wise. Since single-underscore names are reserved by the engine itself, the creators can use that to implement privacy for some data not meant to be accessed directly from outside the subsystem they’re creating.
We did not even document what the mangled name results in, which is a clear philosophical divergence from the python ethos.
It’s something that’s not comparable to defining a class inside another class’s body, since the created thing (function, class or even variable) can then be used by any function or class defined in the same file. But then, in our case it’s just a privacy thing, so for reasons previously mentioned it wouldn’t fit in Python.