About classes and OOP in Python

[bruno at modulix]

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