data hiding/namespace pollution

Alex Hunsley lard at tardis.ed.ac.molar.uk
Mon Oct 31 16:52:54 CET 2005


Steven D'Aprano wrote:
> On Mon, 31 Oct 2005 10:35:19 +0000, Alex Hunsley wrote:
> 
> 
>>There's no really specific questions in this post, but I'm looking for 
>>people's thought on the issues within...
>>
>>
>>The two main versions I've encountered for data pseudo-hiding 
>>(encapsulation) in python are:
>>
>>method 1:
>>
>>_X  - (single underscore) - just cosmetic, a convention to let someone
>>       know that this data should be private.
> 
> 
> Not quite.
> 
> In modules, names starting with one or more underscore (_X, __X, etc.) are
> not copied over when you import the module using "from module import *".

And you can also control what gets exported by defining __all__ I 
believe....

> 
> In classes, instance._X is just a convention "this is private, don't touch
> unless you really have to".

ah, ok.

 >[snip some more details]

Thanks for your helpful response, it's clarifying a few things for me!

> What are you doing, manually keeping a list of "allowed" attributes which
> you check before hand?
> 


Heheh. No, I'm not actually 'doing' anything yet, I'm  findout out what 
is good practise in python land.


> There is, at least, an argument in favour of using that technique for
> enforcing something like attribute declarations:
> 
>     def __setattr__(self, name, value):
>         if name in self.ALLOWED:
>             self.__dict__[name] = value
>         else:
>             raise ValueError("That attribute hasn't been declared.")
> 
> although that just leads into the whole "bondage and domination language"
> can of worms.
> 
> In any case, you already have a perfectly good list of attributes.
> Actually, two lists, one for class attributes and one for instance
> attributes:
> 
> instance.__class__.__dict__.keys() 
> instance.__dict__.keys() 
[snip]

okeydoke.
thanks for the advice!
alex



More information about the Python-list mailing list