[Tutor] Public, private and protected member variables.

[Marc Barry]

Thanks for your feedback Alan. 

I guess my reasoning for most of my statements comes from all of those Java
design principles that I have become so accustomed too. I am now beginning to
understand the Python handles these types of things. I remember being very
confused in the beginning with iterators under Python. I searched through the
documentation and all that was stated was an iterator protocol. I was looking
for some sort of interface. Now the concept makes complete sense to me. I guess
like the iterator protocol, I will just state in the documentation which
objects and variables should not be modified and which methods control internal
state and leave it up to the programmer to abide by the "protocol".

I think that I too am becoming accustomed to the Pythonic ways.

Alan, thanks for the comments. I come from the background of Java, which is
very strict and it has made Python feel somewhat unnatural to me. Although, the
more often I use Python the more it grows on me.

Regards,

Marc

>From: "Alan Gauld" <alan.gauld at blueyonder.co.uk>
>To: "Marc Barry" <marc_barry at hotmail.com>,<tutor at python.org>
>Subject: Re: [Tutor] Public, private and protected member variables.
>Date: Fri, 17 Oct 2003 23:45:43 +0100
>
> > I have a question regarding the existence of protected members in
>Python.
>
>We had a longish thread on variable scoping in Python just recently,
>try searching the archives.
>
> > Basically, in a language like Java we have public, private and
>protected
> > member variables.
>
>Indeed, Java copied the concept from C++ which introduced it
>in version 2, partly to help manage complexity in the face of
>multiple inheritance(also introduced in version 2).
>
> > But in Python I only know of public and private.
>
>And even private can be bypassed fairly easily (as it can
>in C++!) and in practice public variables are the norm.
>
> > inherit from a class and be able to modify parent member variables,
> > but I would not like any class that doesn't inherit from the parent
> > to be able to modify the member variables
>
>Why? Apart from paranoia born from exposure to languages
>like C++ and Java(which as I say just played copycat?)
>
>OO programmers have been using inheritance for many years
>without protected scopes (and originally often without
>private either!) and it very rarely causes problems.
>If you really do need to hide the variables completely
>then simply make them private and then provide accessor
>functions(yuk!) or make them properties(slightly better).
>The accessor can if you really want to, check the immediate
>parent of the calling class...if you really want to...
>
>But do you habitually find yourself breaking your own design
>by trying to directly access internal state? Or do you really
>distrust your fellow programmers that much? And what about
>the occasions when internal access is actually needed by
>a non child class? C++ provides the friend construct,
>should Python do likewise?
>
>Its easier to just go with the flow when using a new language.
>One of the reasons that C++ and Java are so verbose and
>difficult to use is that they introduce all manner of
>artificial restictions which programmers have to work around.
>(And I say that as someone who used C++ almost exclusively
>from 1988 through to 1996 - then I found Delphi, hooray!
>Then I found Python, double hooray! And I haven't written
>any serious C++ since 1999. And I studiously avoid Java as
>much as possible) Python tries to make the programmers life
>easy at the expense of expecting a little courtesy to be
>exercised.
>
> > If I expose a variable in Car as public ,then I will allow users of
>the
> > class to modify it directly. I would like to avoid this since that
>fixes my
> > implementation to being always having to provide a variable named
>"colour"
> > for example.
>
>If that's your concern you could override setattr and getattr
>to prevent access to anything that wasn't a method. That
>way all attributes are private. Then you have to provide
>accessor functions - is that really any better?
>
>Alternatively, in your documentation just tell users not
>to access the attributes directly. And that doing so may result
>in undefined behaviour!
>
> > is much more complicated with a lot of gettable and settable
>properties in
> > the parent object (Which I want to inherit).
>
>Yep, that's why lots of gettable/settable properties are a pain.
>See the previous thread... Sorry but the gettable/settable stuff
>is one of my hot buttons :-(
>
>Alan G
>Author of the Learn to Program web tutor
>http://www.freenetpages.co.uk/hp/alan.gauld
>

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com