Does Python really follow its philosophy of "Readability counts"?
kyrie at uh.cu
Wed Jan 21 21:23:55 CET 2009
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:
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.
More information about the Python-list