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 '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
