[Tutor] pseudo-private but protected?

Marilyn Davis marilyn at deliberate.com
Mon Feb 23 18:26:53 EST 2004


Sorry, I skipped an important word:

On Mon, 23 Feb 2004, Marilyn Davis wrote:

> 
> On Mon, 23 Feb 2004, Alan Gauld wrote:
> 
> Thank you!
> 
> > > I think I get the pseudo-private name-mangling device.
> > >
> > > Are there any conventions or devices for 'pseudo-protected'
> > attributes
> > > and methods in Python?
> > 
> > As a matter of interest, why do you think such a thing would be
> > useful?
> 
> Oh. I don't!  I just anticipate C++ people to ask the question and
> want to be sure the answer is that it is not supported.
> 
> Or, I guess it could be useful if a (possibly virtual) base class had
> base.set_name(), and its sub_classes are expected to call
> base.set_name() in their sub_class.set_name() methods but we don't
> want the base.set_name() method to be available outside the class.

... outside the class *hierarchy*.

> 
> > 
> > > These are accessible by members of the hierarchy, but not outside.
> > 
> > That's one definition of protected, as used in Java and C++.
> > It's not a universal definition - Delphi for example takes another
> > approach. The "protected method" style of OO programming is best
> > used as a form of protection for the programmer when dealing with
> > statically typed languages with function overloading based on
> > typed parameters. It basically provides a means of simplifying
> 
> I guess this isn't my example.
> 
> > the public interface while allowing access to multiple typed
> > versions of that interface. Since Python does not use that mechanism,
> > protected methods are somewhat irrelevant.
> 
> Oh.
> 
> > 
> > Which is why I ask why you thought you might want them?
> 
> Does my example make my question make sense?
> 
> Marilyn
> 
> > 
> > Alan G.
> > 
> > 
> 
> 

-- 




More information about the Tutor mailing list