Protected Methods and Python

[Venkatesh Prasad Ranganath]

Jp Calderone wrote:
> On Sun, Apr 13, 2003 at 09:26:37PM +0200, Mads Orbesen Troest wrote:
> 
>>On Sun, 13 Apr 2003 21:24:24 +0200, Mads Orbesen Troest wrote:
>>
>>
>>>>Or may be it is possible to emulated Protected Methods in Python.
>>>
>>>It can be "emulated" by prepending the method/attribute name with 2 
>>>underscores. 
>>
>>Whoops, I was too quick and didn't see that you wrote "protected" and not 
>>"private".
>>
>>At any rate: the mangling scheme can be used for "protected" methods, since 
>>you know the mangled name is _classname__attribute/method. You can then be 
>>one of the "evil" persons I talked about in the previous post, and access 
>>the "private" member that way.
>>
> 
> 
>   Double underscore prefix is for avoiding name collisions in inheritance,
> not preventing people from touching things you consider private to the
> implementation.
> 
>   Language enforced private attributes are a Wrong idea because they
> needlessly increase the difficulty of people trying to use code which
> employs this feature.
> 
>   There are a few possible scenarios:
> 
>   1) I am a skillful coder and I am using a library written by a skillful
> coder.  The library is bug-free (for the purpose which I use it) and I have
> no need to touch the implementation's internal variables.  In this scenario,
> runtime protected private attributes are not useful.
> 
>   2) I am not a skillful coder and I am using a library written by a
> skullful coder.  The library is bug-free (for the purpose which I use it)
> but I feel the need to touch the implementation's internal variables anyway. 
> Whether or not they are protected by the runtime environment, I will
> probably find a way to screw up my application, because I am not skilled. 
> In this scenario, runtime protected private attributes are not useful.
> 
>   3) I am a skillful coder and I am using a library written by someone who
> is not skillful.  The library contains bugs which disrupt my application. 
> In this scenario, runtime protected private attributes make it impossible
> for me to work around bugs in the library, and so are worse than useless.
> 

All said, how do you ensure "design by interface" in Python?   If every feature of a class is open to the user then he/she 
will use them as he/she sees fit.  However, the writer of the class could have coded some methods for ancillary purposes and 
later decides to do away with them in the next version of the class.  How should the user deal with this situation?  In my 
opinion, protected and private as in C++ or Java empowers the library developer to expose just the interface that he/she 
intends the user to see.  Nothing more and nothing less.  (It's an issue dealing with abstraction.)  As a result, the user can 
be more care-free while using the library code as he cannot screw up the internals if the library code doesn't do it on it's 
own.  On the other hand, if all members of a class are visible to the user then the user needs to be more diligent while using 
the library.  I prefer the first option.

On the issue of working around bugs in a library via runtime protected attributes, it would be better if the skillful coder 
fixed the bug ;-) or use another library.  This is just what I would do.

Well, that's my opinion.

>   Since Python provides no real runtime protection of private attributes,
> the best you can hope to do is make it excessively painful for people using
> your code to work around your bugs.  I can't imagine why anyone would want
> to do this.
> 
>   If an attribute is private to your implementation, document it this way
> and prefix it with a single underscore.  Nothing else is necessary.
> 
>   high-and-mightily y'rs,
> 
>   Jp
> 


-- 

Venkatesh Prasad Ranganath,
Dept. Computing and Information Science,
Kansas State University, US.
web: http://www.cis.ksu.edu/~rvprasad