Newbie Q: Class Privacy (or lack of)

[Marc 'BlackJack' Rintsch]

In <44C9B607.B0FFBAC3 at rotten.apple.commie>, Steve Jobless wrote:

> Bruno Desthuilliers wrote:
>> 
>> Steve Jobless wrote:
>> > But what about adding a method to the class? Am I supposed to ask "Is
>> > anyone using name xxx?"
>> 
>> assert 'xxx' not in dir(SomeClassOrObject)
>> 
>> > The class may be used by  developers I don't
>> > even know and some of them may be on the other side of the planet...
>> 
>> How could this be a problem ? What's added/changed at runtime in a given
>> app doesn't impact the source code.
> 
> Say you are a 3rd party library developer. You can tell your customers
> to check dir(MyClass), but you can't enforce it. Even if they do, just
> updating your library could break THEIR code. It's not your fault, but
> you have to patiently diagnose their problem and nicely tell them it's
> their fault.

But if they mess with the objects of your library I expect them to check
first if this is the cause of the failures.  They hopefully *know* where
they crossed the line into my implementation.  Because adding a method to
a "foreign" class is semantically the same as writing it directly into the
source code of that library.

This should be done only when it's really needed and it should be
documented.  Just because it's possible doesn't mean it's the way to solve
most problems that may be better solved by inheritance.

>> Just one example : suppose you're working with a framework. Suppose
>> you'd need to customize some objects (including classes - Python classes
>> are objects too) of the framework, but the framework has no hook for
>> this and you definitively don't wan't to bother patching the code and
>> maintaining your own branch.
>> 
> 
> <IMHO>
> 
> Maybe it's cultural. But one aspect of OO is that you only need to know
> what the object does (interface), but you don't have to (and better not)
> know how it does (implementation). This is important because the class
> implementor can enhance and/or optimize the class without breaking
> users' code as long as the interface is compatible. (This is why most,
> if not all, instance variables should be private. You can use
> __getattr__/__setattr__, but they don't always work.) If you need to
> customize a class, you should sub-class it using the public interface of
> the base class. You better not mess with it from the outside because
> updating the class can break your code. Unfortunately, I don't see a way
> to separate interface from implementation in Python. So, it may not make
> much difference whether you subclass it or hack it from the outside.

It makes a difference.  If you subclass the chances that your modification
breaks if the implementation of the library class changes is much lower. 
Pythonistas expect a programmer to know this and act accordingly.

Separating interface and implementation is done by naming conventions in
Python.  If a name starts with an underscore it's not part of the API.

> I was hoping someone shows me a compelling reason to sacrifice the
> safety, but I don't hear much.
>
> It looks pretty good as long as it is used by a small
> group, especially for a small project. (Or Python is meant just for such
> projects?)

Please prove that the safety is sacrificed to the extent that you fear. 
This "if you don't have `private`, everything starts to fall apart and
explodes right in your face if the project starts to get bigger" arguments
aren't backed by empirical data either but often seems to be just learned
by heart in Java and C++ courses.

Ciao,
	Marc 'BlackJack' Rintsch