Making immutable instances

[Steven D'Aprano]

On Thu, 24 Nov 2005 12:55:07 +0000, Antoon Pardon wrote:

> Suppose I have the following code.
> 
> from module import __take_care__
> 
> __private_detail__ = ...
> 
> I now have two variable that are flaged the same way, but they are not.

No, you have two names written using a poor naming convention.

__name__ should be used only for Python's special methods.

> __take_care__ is a private variable from an other module which I should
> use with extreme care not to break the other package.

Python doesn't do any special treatment of __name or __name__ from
modules. The only information hiding techniques Python enforces are that
module._name (single leading underscore) is not imported by "from module
import *", and class.__name (double leading underscore) is mangled to
class._Class__name.

Both techniques are done in order to let the module creator protect users
from *accidentally* shooting themselves in the foot, while still allowing
the module users to *deliberately* shoot themselves in the foot if that is
what they need or want to do. Deliberately breaking these information
hiding techniques are features, not bugs.


> __private_detail__ on the other hand is just keeping private data for my
> own module, which I should care about as just any other variable in my
> module. 

If you care about keeping __private_detail__ no more than you care about
public_detail, what makes one private and one public?


> It are other modules that should take special care if they
> should choose to import this variable.

I'm not sure what the difference is. If there is a difference, why are you
using the same naming convention for different sorts of names ("private
module variable" and "private module data"). If there is no difference, I
don't understand the point of your example.


-- 
Steven.