Making immutable instances
steve at REMOVETHIScyber.com.au
Sat Nov 26 01:49:18 CET 2005
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
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
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.
More information about the Python-list