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!

[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 !-)

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"

[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,
encapsulatio n, 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 "inheritanc e" an important buzzword for OOP?
--
Regards,
Casey

[Ben C]

On 2006-04-11, Michele Simionato <mi************ ***@gmail.com> wrote:

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. 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.

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]

On Tue, 11 Apr 2006 18:20:13 +0000, Casey Hawthorne wrote:

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 "inheritanc e" 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.

--
Steven.

[Ben Cartwright]

Michele Simionato wrote:

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. 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.

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]

Steven D'Aprano schrieb:

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

VB4 - VB6

--
Mit freundlichen Grüßen,
Ing. Gregor Horvath, Industrieberatu ng & Softwareentwick lung
http://www.gregor-horvath.com

[bruno at modulix]

Ben C wrote:

On 2006-04-11, Michele Simionato <mi************ ***@gmail.com> wrote:

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. 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.

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 desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"

[bruno at modulix]

Casey Hawthorne wrote:

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 "inheritanc e" 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__).
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"

[Magnus Lycka]

Michele Simionato wrote:

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. 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.

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]

Gregor Horvath wrote:

Steven D'Aprano schrieb:

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

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...

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom. gro'.split('@')])"