data hiding/namespace pollution

Alex Hunsley lard at tardis.ed.ac.molar.uk
Mon Oct 31 06:19:44 EST 2005


bruno at modulix wrote:
> 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) 
> 
> 
> <OT>
> Hmmm... Are data-hiding and encapsulation really the same things ?
> </OT>

No, they're not, I was just being careless there, please disregard any 
apparent implication that they are.

>>in python are:
>>
>>method 1:
>>
>>_X  - (single underscore) - just cosmetic, a convention to let someone
>>      know that this data should be private.
>>
>>
>>method 2:
>>
>>__X - (double underscore) - mangles the name (in a predictable way).
>>      Avoids name pollution.
>>
>>
>>How often does either tend to get used? Personally, I'd be a little
>>worried about using method 1, because namespace clashes could happen. Is
>>this overly paranoid?
> 
> 
> Probably.
> 
> Note that prefixing names with a single underscore have a 'protected'
> semantic - which means that such names (well, the objects that are bound
> to...) can be overriden/extends by child classes.

Ah, my mistake, not merely cosmetic then! Thanks.

> 
> I personnally only use the double-underscore notation only for things
> that are *really* implementation-specific *and* should *really not* be
> overriden.

ok.

>>Also, I presume that rather than people writing their own manual getter
>>and setter methods, they tend to use either overloading on __getattr__
>>and __setattr__, or the Property class (which itself uses aforementioned
>> methods). 
> 
> 
> Yeps... This is the pythonic way.
> 
> 
>>Overloading __getattr__ etc. seems more attractive to me, as
>>then I can capture access to unknown names, and raise an exception!
>>(I really don't like the idea of random attribute name typos going
>>unnoticed when accessing attributes in a class!)
> 
> 
> Err... Have you *really* tried to access an inexistant attribute ?  This
> is usually not 'unnoticed' (unless you consider the raising of an
> AttributeError as being the same as 'unnoticed' !-)

Sorry, I wasn't being clear. What I should have said is that I don't 
like the idea of a typo in an assignment causing the assigning of the 
wrong thing.
e.g. imagine a simple value-holding class:

class Values:
	pass

v = Values()

v.conductoin = 10


... I meant to type 'conduction' in the source but spelt it wrong.
My value won't be there when elsewhere I refer to the correct attribute: 
"conduction".



> I personnaly use 'magic' accessors only for delegation or like, and
> properties (or custom descriptors) for anything else (that requires
> it...). This avoid the Big-Switch-Syndrom in __getattr__ and setattr__,
> and is much more explicit (API, documentation, introspection etc...).

Right, good point.

>>Note: I do know that the use of the above things is quite dependent on
>>what exactly you're coding, the size of the project etc., but what I'm
>>trying to find out about is the python communities' recognised good
>>practices.
> 
> 
> Then launch your python interactive shell and type "import this"

Thanks for that, I didn't know about that!
alex



More information about the Python-list mailing list