Newbie Q: Class Privacy (or lack of)

[Steve Jobless]

Bruno Desthuilliers wrote:
> 
> Steve Jobless wrote:
> > Sybren Stuvel wrote:
> >
> >>Steve Jobless enlightened us with:
> >>
> >>>The first case can be just a typo, like:
> >>>
> >>>  x.valeu = 5
> >>>
> >>>I make typos all the time. Without a spell checker, this message
> >>>would be unreadable :).
> >>
> >>Then learn to read what you type, as you type it. Typing without
> >>errors can be trained.
> >
> >
> > I'd rather let a machine to do that. Wasn't computer created for tasks
> > like this? (No, not really. But...)
> 
> There's obviously a trade-off between 'security' and flexibility. As I
> said, I do make lots of typo too, but OTOH the edit/test cycle in Python
> is usually so short that such errors are not a problem for me - they're
> caught almost immediatly.

I hope you are right. But I have yet to see the proof. Just empirical arguments.

> 
> >
> >>>The second case can be like:
> >>>
> >>>  x.next = y
> >>>  y.next = None
> >>>
> >>>to create a linked list by piggybacking "next" to the class. It will
> >>>overwrite the iterater for the class if defined.
> >>
> >>You shouldn't simply pick a name and assign something to it without
> >>checking the current use of that name. It's pretty much true for
> >>everything in life.
> >
> >
> > Well, the choice of "next" was not a good example. Sure, no one with
> > decent Python knowledge would do that.
> > 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. It's not a good idea to call them "idiots." This may be an
extreme case, but it could happen within a single organization. You may
be in the framework group supporting several application groups.

> 
> >
> >>>If I was working on a large project with many engineers, I'd assume
> >>>someone will do things like this sooner or later. I've seen many
> >>>horrendous code in my life and I have no control over who I work
> >>>with.
> >>
> >>Long live a versioning system. With that, you can find the person
> >>writing the horrible code, and slap them on the back of the head.
> >>People, like all animals, can be trained into doing the right thing.
> >
> >
> > I'd like to. But often those people are long gone for one reason or
> > another. Sometimes, it happens to be my boss...
> 
> If your boss is a bad programmer and doesn't know it, then you're in for
> trouble whatever the language.
> 
> >
> > Maybe I should ask the question in a different way:
> >
> > What are the benefits from this? There must be something really good
> > (and hopefully safe) you can do with it only from the outside. I don't
> > have much problem over-riding functions from the inside of the class.
> > But from the outside, I fail to see why anyone needs to add attributes
> > or over-ride functions.
> 
> 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.

Python has some good features. The memory management using reference
counting with garbage collection is very attractive. It can even do
delegation! Unfortunately, it seems to be taking unnecessary risk. 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?) But I don't feel comfortable enough for a large project that
involves multiple groups including 3rd parties in a long duration. I
just wish those "features" would be removed or at least made optional.

</IMHO>

Have a good weekend, everyone.

SJ