is python Object oriented??

[Luis Zarrabeitia]

On Monday 02 February 2009 04:51:11 pm Russ P. wrote:
> As I said before, as an aeronautical engineer I don't know if enforced
> access restriction can be added to Python without compromising or
> unduly complicating the language. Maybe it can't. If that's the case,
> then people should make that argument. But just saying that enforced
> access restriction is useless in general is nonsense. Are we supposed
> to believe that the designers of C++, Java, Ada, and Scala are all
> idiots?

I'm amazed at how quickly this thread degenerated into another 'enforced data 
hiding' thread. I think the previous one ran long enough for me to actually 
say that 'access restriction is nonsense', when my point had been '_enforced_ 
access restrictions in python is worthless in all the examples provided so 
far' (except perhaps the extensions modules, but those are not python).

You are an aeronautical engineer. You, and I understand that, don't want, 
shouldn't want, and will not want to run anything you cannot trust. You want 
the most assurances you can get. You are well within your right to want 
that - to disallow in your systems, and in the systems that you build, 
anything that you even suspect that may threaten the integrity of the system, 
and let's face it, breaking the encapsulation, intentional or not, is pretty 
suspicious.

So, in current python, _you_ have the _choice_ of preventing it. As the checks 
are static, of course, you can break them in runtime, just like you would in 
C, C++ and Java.

But somehow, it is not enough for you that you have the choice, because that 
also gives _me_ the choice of _not_ doing it in my own systems. And you still 
haven't said why it bothers you that I have the choice.

Now, if you were arguing for [truly optional - as in, the user decides] 
dynamic checks, you may see a very different position. That RExec and Bastion 
even existed should tell you that there is interest on implementing some kind 
of trusted execution (as in 'I trust this code to do whatever it wants, but 
not this other code'). That both projects failed should tell you that either 
it is impossible to achieve in python (which would be bad), or that there is 
just not enough interest on keeping them (which would not amaze me). But, if 
you are arguing for dynamic checks, those are not present in C++ either, and 
thus, it isn't really what you mean with enforced data hiding.

> If an assignment to the previously
> "private" attribute is missed, no warning will be issued (because
> Python allows new attributes to be added anywhere, even completely
> outside the class definition itself). And if the library is widely
> used, the probability of such bugs occurring is very high.

Good coding standards would prevent that. And by good coding standards, I 
mean "treat pylint and similar tools as a requirement before executing any 
code", and it will catch that sort of bugs. Again, _you_ have the choice. Use 
it if you wish.

Now, I'm with you in that accidental variable creation is a nasty side effect 
of python dynamism (and that you may be forfeiting it if you go the pylint 
route). But that particular complaint has nothing to do with enforced vs 
not-enforced data hiding, and everything to do with static typing. And mind 
you, must of us who use python, do so _because_ of the dynamism and not in 
spite of it.

Funny thing is, you have the choice, _now, today_, of having your precious 
static checks, both of them, for your projects. But you keep complaining 
because I also have the choice, and I may chose not to have them.

-- 
Luis Zarrabeitia (aka Kyrie)
Fac. de Matemática y Computación, UH.
http://profesores.matcom.uh.cu/~kyrie