On Wednesday 21 January 2009 02:03:07 pm Paul Rubin wrote: > Luis Zarrabeitia <ky...@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 -- http://mail.python.org/mailman/listinfo/python-list
