About classes and OOP in Python

[fyhuang]

Hello all,

I've been wondering a lot about why Python handles classes and OOP the
way it does. From what I understand, there is no concept of class
encapsulation in Python, i.e. no such thing as a private variable. Any
part of the code is allowed access to any variable in any class, and
even non-existant variables can be accessed: they are simply created.
I'm wondering what the philosophy behind this is, and if this
behaviour is going to change in any future release of Python.

It seems to me that it is difficult to use OOP to a wide extent in
Python code because these features of the language introduce many
inadvertant bugs. For example, if the programmer typos a variable name
in an assignment, the assignment will probably not do what the
programmer intended.

Ruby does something with this that I think would be excellent as an
inclusion in Python (with some syntax changes, of course). If private
variables require a setter/getter pair, we can shortcut that in some
way, i.e. (pseudocode):

class PythonClass:
private foo = "bar"
private var = 42
allow_readwrite( [ foo, var ] )

Or allow_read to only allow read-only access. Also there might be a
way to implement custom getters and setters for those times you want
to modify input or something:

class PythonClass:
def get foo():
return "bar"

def set var( value ):
var = value

Anyways, these are just some speculatory suggestions. My main question
is that of why Python chooses to use this type of OOP model and if it
is planned to change.

Thanks!

 

[danmcleran]

You can do this in Python as well. Check out the property built-in
function. One can declare a property with a get, set, and delete
method. Here's a small example of a read-only property.

class Test(object):
def getProperty(self):
return 0;

prop = property(fget = getProperty)

t = Test()

print t.prop

t.prop = 100 # this will fail

 

[Roy Smith]

I've been wondering a lot about why Python handles classes and OOP the
way it does. From what I understand, there is no concept of class
encapsulation in Python, i.e. no such thing as a private variable. Any
part of the code is allowed access to any variable in any class, and
even non-existant variables can be accessed: they are simply created.
I'm wondering what the philosophy behind this is, and if this
behaviour is going to change in any future release of Python.

There are advantages and disadvantages to C++/Java style encapsulation
using private data. The advantages you (apparently) already know. The
disadvantage is added complexity. There's a saying, "You can't have a bug
in a line of code you never write". By having to write all those getter
and setter methods, you just add bulk and complexity.

That being said, you can indeed have private data in Python. Just prefix
your variable names with two underscores (i.e. __foo), and they effectively
become private. Yes, you can bypass this if you really want to, but then
again, you can bypass private in C++ too. You can also intercept any
attempt to access Python attributes by writing __getattr__() and
__setattr__() methods for your class.

It seems to me that it is difficult to use OOP to a wide extent in
Python code because these features of the language introduce many
inadvertant bugs. For example, if the programmer typos a variable name
in an assignment, the assignment will probably not do what the
programmer intended.

Yes, that is is a risk. Most people deal with that risk by doing a lot of
testing (which you should be doing anyway). If you really want to, you can
use the __slots__ technique to prevent this particular bug from happening
(although the purists will tell you that this is not what __slots__ was
designed for).

My main question is that of why Python chooses to use this type of OOP
model and if it is planned to change.

It sounds like you are used to things like C++ and Java, which are very
static languages. Everything is declared at compile time, and there are
many safeguards in the language to keep you from shooting yourself in the
foot. They problem is, they often prevent you from getting any useful work
done either; you spend most of your time programming the language, not the
problem you are trying to solve.

In the past week, I've had two conversations with people about the nuances
of C++ assignment operators. None of our customers give two figs about
assignment operators. Getting them right is just a detour we need to take
to keep our software from crashing. With Python, I write a = b and trust
that it does the right thing. That lets me concentrate on adding value
that our customer will see.

 

[Felipe Almeida Lessa]

Em Seg, 2006-04-10 às 07:19 -0700, fyhuang escreveu:

class PythonClass:
private foo = "bar"
private var = 42
allow_readwrite( [ foo, var ] )

You are aware that foo and var would become class-variables, not
instance-variables, right?

But you can always do:

class PythonClass(object):
def __init__(self):
self.__foo = "bar"

foo = property(lambda self: self.__foo)


And then:
Traceback (most recent call last):
File "<stdin>", line 1, in ?
AttributeError: can't set attribute


But you can also bypass this "security":
'baz'


But this was not a mistake, nobody mistakenly writes "_PythonClass__".

Or allow_read to only allow read-only access. Also there might be a
way to implement custom getters and setters for those times you want
to modify input or something:

class PythonClass:
def get foo():
return "bar"

def set var( value ):
var = value

There's a PEP somewhere that proposes things like (same example I gave
earlier):

class PythonClass(object):
def __init__(self):
self.__foo = "bar"

create property foo:
def get(self):
return self.__foo

 

[Sion Arrowsmith]

[ ... ] no such thing as a private variable. Any
part of the code is allowed access to any variable in any class, and
even non-existant variables can be accessed: they are simply created.

You're confusing two issues: encapsulation and dynamic name binding.
You might also want to check out the difference between read and
write access to non-existant variables.

I'm wondering what the philosophy behind this is,

"We are all consenting adults." And probably experience of data
encapsulation being more of a hinderence than a benefit.

and if this
behaviour is going to change in any future release of Python.

I damn well hope not.

And if you want to control those writes, try this for a base class:

class restrict_set:
def __init__(self, allowed_names):
self._allowed_names = set(allowed_names)
def __setattr__(self, name, value):
if not name.startswith('_') and name not in self._allowed_names:
getattr(self, name)
self.__dict__[name] = value

(Someone else can do the new style class and the metaclass versions.)

 

[Gregor Horvath]

Hi,

I've been wondering a lot about why Python handles classes and OOP the
way it does. From what I understand, there is no concept of class
encapsulation in Python, i.e. no such thing as a private variable. Any

the answer is here:

http://tinyurl.com/obgho

 

[Ben Sizer]

It seems to me that it is difficult to use OOP to a wide extent in
Python code because these features of the language introduce many
inadvertant bugs. For example, if the programmer typos a variable name
in an assignment, the assignment will probably not do what the
programmer intended.

You'll find that if you assign to a wrongly-typed variable name, then
later attempts to access the variable you wrongly believed you typed
will raise an exception. If you assign from a wrongly-typed variable,
again an exception will be raised.

I think it's important not to wrongly confuse 'OOP' with ''data hiding'
or any other aspect you may be familiar with from Java or C++. The
primary concept behind OOP is not buzzwords such as abstraction,
encapsulation, polymorphism, etc etc, but the fact that your program
consists of objects maintaining their own state, working together to
produce the required results, as opposed to the procedural method where
the program consists of functions that operate on a separate data set.

 

[Fredrik Lundh]

I think it's important not to wrongly confuse 'OOP' with ''data hiding'
or any other aspect you may be familiar with from Java or C++. The
primary concept behind OOP is not buzzwords such as abstraction,
encapsulation, polymorphism, etc etc, but the fact that your program
consists of objects maintaining their own state, working together to
produce the required results, as opposed to the procedural method where
the program consists of functions that operate on a separate data set.

+1 QOTW

</F>

 

[Michele Simionato]

Roy Smith wrote:

That being said, you can indeed have private data in Python. Just prefix
your variable names with two underscores (i.e. __foo), and they effectively
become private. Yes, you can bypass this if you really want to, but then
again, you can bypass private in C++ too.

Wrong, _foo is a *private* name (in the sense "don't touch me!"), __foo
on the contrary is a *protected* name ("touch me, touch me, don't worry
I am protected against inheritance!").
This is a common misconception, I made the error myself in the past.

Michele Simionato

 

[bruno at modulix]

Hello all,

I've been wondering a lot about why Python handles classes and OOP the
way it does. From what I understand, there is no concept of class
encapsulation in Python, i.e. no such thing as a private variable.

Seems you're confusing encapsulation with data hiding.

Any
part of the code is allowed access to any variable in any class,

This is also true for Java and C++ - it just a requires a little bit
more language-specific knowledge.

Python relies a lot on conventions. One of these conventions is that any
attribute whose name begins with an underscore is implementation detail
and *should* not be accessed from client code.

and
even non-existant variables can be accessed:

Nope. You can dynamically *add* new attributes - either to an instance
or a class - but trying to *read* a non-existant attribute will raise an
AttributeError.

they are simply created.
I'm wondering what the philosophy behind this is,
Dynamism.

and if this
behaviour is going to change in any future release of Python.

Certainly not.

It seems to me that it is difficult to use OOP to a wide extent in
Python code because these features of the language introduce many
inadvertant bugs.

Don't assume, verify. My own experience is that it's *much more* easy to
do OOP with a dynamic language.

For example, if the programmer typos a variable name
in an assignment, the assignment will probably not do what the
programmer intended.

That's true for any language. I never had any serious problem with this
in 5+ years - not that I'm never making typos, but it never took me more
than a pair of minutes to spot and correct this kind of errors. OTOH,
Python's dynamism let me solved in a quick and clean way problems that
would have been a royal PITA in some less agile languages.

Ruby does something with this that I think would be excellent as an
inclusion in Python (with some syntax changes, of course). If private
variables require a setter/getter pair, we can shortcut that in some
way, i.e. (pseudocode):

class PythonClass:
private foo = "bar"
private var = 42
allow_readwrite( [ foo, var ] )

A first point: in Ruby (which closely follows Smalltalk's model),
there's a definitive distinction between callable and non-callable
attributes, and this last category is *always* private.

A second point is that Python also provides you getter/setter for
attributes. The default is read/write, but you can easily make any
attribute read-only (or write-only FWIW) and add any computation.

Or allow_read to only allow read-only access. Also there might be a
way to implement custom getters and setters for those times you want
to modify input or something:

class PythonClass:
def get foo():
return "bar"

def set var( value ):
var = value

What you want is named "property".

Anyways, these are just some speculatory suggestions.

Don't waste time with speculations. Read the Fine Manual instead, and
actually *use* Python.

My main question
is that of why Python chooses to use this type of OOP model and if it
is planned to change.

I'm not the BDFL, but my bet is that this will *not* change.

 

[bruno at modulix]

Roy Smith wrote:
(snip)

That being said, you can indeed have private data in Python. Just prefix
your variable names with two underscores (i.e. __foo), and they effectively
become private.

The double-leading-underscore stuff has nothing to do with "privacy".
It's meant to protect from *accidental* overriding of implementation stuff.

(snip)

Yes, that is is a risk. Most people deal with that risk by doing a lot of
testing (which you should be doing anyway). If you really want to, you can
use the __slots__ technique to prevent this particular bug from happening
(although the purists will tell you that this is not what __slots__ was
designed for).

Ok, so I must be a purist !-)

 

[Casey Hawthorne]

I think it's important not to wrongly confuse 'OOP' with ''data hiding'

or any other aspect you may be familiar with from Java or C++. The
primary concept behind OOP is not buzzwords such as abstraction,
encapsulation, polymorphism, etc etc, but the fact that your program
consists of objects maintaining their own state, working together to
produce the required results, as opposed to the procedural method where
the program consists of functions that operate on a separate data set.

Isn't "inheritance" an important buzzword for OOP?

 

[Ben C]

Roy Smith wrote:

Wrong, _foo is a *private* name (in the sense "don't touch me!"), __foo
on the contrary is a *protected* name ("touch me, touch me, don't worry
I am protected against inheritance!").
This is a common misconception, I made the error myself in the past.

Please explain! I didn't think _foo meant anything special, __foo
expands to _classname__foo for some sort of name-hiding. What am I
missing?

 

[Steven D'Aprano]

Isn't "inheritance" an important buzzword for OOP?

Of course inheritance is an important and desirable feature of OOP, but it
isn't a necessary feature. Python built-in objects like int, list etc.
were still objects even before you could inherit from them.

I don't know of many other OO languages that didn't/don't have
inheritance, but there was at least one: Apple's Hypertalk, back in the
late 80s early 90s.

 

[Ben Cartwright]

Roy Smith wrote:


Wrong, _foo is a *private* name (in the sense "don't touch me!"), __foo
on the contrary is a *protected* name ("touch me, touch me, don't worry
I am protected against inheritance!").
This is a common misconception, I made the error myself in the past.

Sure, if you only consider "private" and "protected" as they're defined
in a dictionary. But then you'd be ignoring the meanings of the
public/private/protected keywords in virtually every language that has
them. http://www.google.com/search?q=public+private+protected

Python doesn't have these keywords, but most Python programmers are at
least somewhat familiar with a language that does use them. For the
sake of clarity:
__foo ~= private = used internally by base class only
_foo ~= protected = used internally by base and derived classes

The Python docs use the above definitions.

--Ben

 

[Gregor Horvath]

I don't know of many other OO languages that didn't/don't have
inheritance,

VB4 - VB6

 

[bruno at modulix]

Please explain! I didn't think _foo meant anything special,

It doesn't mean anything special in the language itself - it's a
convention between programmers. Just like ALL_CAPS names is a convention
for (pseudo) symbolic constants. Python relies a lot on conventions.

__foo
expands to _classname__foo for some sort of name-hiding.
s/hiding/mangling/

What am I
missing?

the __name_mangling mechanism is meant to protect some attributes to be
*accidentaly* overridden. It's useful for classes meant to be subclassed
(ie in a framework). It has nothing to do with access restriction - you
still can access such an attribute.

 

[bruno at modulix]

Isn't "inheritance" an important buzzword for OOP?

Which kind of inheritance ? subtyping or implementation inheritance ?-)

FWIW, subtyping is implicit in dynamically typed languages, so they
don't need support for such a mechanism. And implementation inheritance
is not much more than a special case of composition/delegation, so it's
almost useless in a language that have a good support for delegation
(which we have in Python, thanks to __getattr__/__setattr__).

 

[Magnus Lycka]

Roy Smith wrote:


Wrong, _foo is a *private* name (in the sense "don't touch me!"), __foo
on the contrary is a *protected* name ("touch me, touch me, don't worry
I am protected against inheritance!").
This is a common misconception, I made the error myself in the past.

While your wording makes sense, it's probably confusing for anyone
with a C++ background, where private roughly means "only accessible
within the actual class" and protected roughly means "only accessible
within the class and other classes derived from it".

 

[bruno at modulix]

Steven D'Aprano schrieb:




VB4 - VB6

VB6 has a kind of inheritance via interface/delegation. The interface
part is for subtyping, the delegation part (which has to be done
manually - yuck) is for implementation inheritance. Needless to say it's
a king-size PITA...