Does Python really follow its philosophy of "Readability counts"?

[Luis Zarrabeitia]

On Wednesday 21 January 2009 02:03:07 pm Paul Rubin wrote:
> Luis Zarrabeitia <kyrie at uh.cu> writes:
> > But somehow the discussion shifted from an optional requirement (giving
> > you the chance to explicitly use 'from lock import unlock; o =
> > unlock(obj)') to "it can't be done _ever_" (using setattr/getattr is as
> > explicit as your analogous 'unlock' function).
>
> The idea was the lock would be on the class, not on instances of the
> class.  So setattr/getattr would work on instances of unlocked classes
> but not locked ones.  If you wanted an unlocked instance of a locked
> class, you could do it by making an unlocked subclass.

Well, then, go change pylint to do that. But don't try to force it on _me_: If 
I want to access an attribute for an object on my program (from wherever it 
came from), I don't want _you_ or anyone else saying "no, its private". 

Even better. Realize that you are trying to use a tool made for debugging, 
documenting, and catching some obvious errors (private/public) 
for "security". Go fix Bastion, that would be your best bet. It was yanked 
out of python because it was insecure, but if someone were to fix it, I'm 
sure the changes would be welcomed. And then, it would be my choice whether 
to let you lock your instances in _my_ program, and it would be yours to lock 
all of mine in yours (and way more).

Btw, when I was programming in .Net (long time ago), I found a little library 
that I wanted to use. The catch: it wasn't opensource, it had a gratis 
version, and a full, payed version... The difference? The full one had some 
attributes public that were private on the free one. Well, I didn't wanted 
code on my app from someone who didn't know the meaning of the 'private' 
keyword anyway. You (well, Russ more than you) almost seem to be trying 
something like that.

> > Btw, the correctness of a program (on a turing-complete language) cannot
> > be statically proven. Ask Turing about it.
>
> That's an irrelevant red herring,

True, my bad.

But I don't think it is _fully_ irrelevant. See, a thread that begun with 
saying that a piece of code was hard to read has evolved to changing the 
language so we could have tools to statically proving "certain things" with 
the code. And each time a "suggestion" appears (from people that, at least at 
the time of suggesting it, were genuinely interested on helping) that doesn't 
fulfill your [plural, including russ] goal of having static typing and data 
hiding in the official python, you shoot it down because some other "it 
cannot be proven statically" reason. Sure, it is always a very well 
defined "certain" thing and not correctness in general, but that "certain" 
thing changes as soon as a suggestion is made to amend it.

I'm obviously growing tired of that pattern.

Have pylint check if someone uses getattr in your code, at all. If pylint 
doesn't do it, just grep for it and don't run that code. Simple.

Btw, this may put and end to this discussion:

import gc
gc.get_objects()

No amount of metaclasses, pylints, decorator, etc, will stop someone from 
using that to get access to _all_ objects of the program. If you need to keep 
a secret, don't put it on the same memory space that the untrusted code in 
python (actually, don't do it on any language). If you need static proofs, 
use a less dynamic subset of python, and use or develop tools to check if you 
tried to get out, ever (because if you get out once, you will not be able to 
track the results). Or, don't use python. (and certainly don't use C++, for 
that matter, even if C++ has a 'private' keyword).

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