Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Preventing execution of a method

Reply
Thread Tools

Preventing execution of a method

 
 
Emanuele D'Arrigo
Guest
Posts: n/a
 
      12-11-2008
Sorry if I'm a bit thick here...

can any of the esteemed participant in this noble newsgroup confirm
that is not possible to prevent a python module's code from executing
the methods of another module?

I.e. if I have a class with two methods, doSomethingSafe() and
doSomethingDangerous(), is there a way to prevent another module from
executing doSomethingDangerous() but allow the execution of
doSomethingSafe()?

My understanding is that in python this is not possible. Can you
confirm?

Manu
 
Reply With Quote
 
 
 
 
alex23
Guest
Posts: n/a
 
      12-11-2008
On Dec 12, 2:07*am, "Emanuele D'Arrigo" <(E-Mail Removed)> wrote:
> I.e. if I have a class with two methods, doSomethingSafe() and
> doSomethingDangerous(), is there a way to prevent another module from
> executing doSomethingDangerous() but allow the execution of
> doSomethingSafe()?
>
> My understanding is that in python this is not possible. Can you
> confirm?


Your understanding is correct.

The Python convention is to prefix non-public methods/classes etc with
an underscore, as in _doSomethingDangerous(). This is meant to
indicate to anyone using your module that they shouldn't use this
function, at least not without having a good understanding of what it
does.
 
Reply With Quote
 
 
 
 
rdmurray@bitdance.com
Guest
Posts: n/a
 
      12-11-2008
On Thu, 11 Dec 2008 at 08:16, alex23 wrote:
> On Dec 12, 2:07*am, "Emanuele D'Arrigo" <(E-Mail Removed)> wrote:
>> I.e. if I have a class with two methods, doSomethingSafe() and
>> doSomethingDangerous(), is there a way to prevent another module from
>> executing doSomethingDangerous() but allow the execution of
>> doSomethingSafe()?
>>
>> My understanding is that in python this is not possible. Can you
>> confirm?

>
> Your understanding is correct.
>
> The Python convention is to prefix non-public methods/classes etc with
> an underscore, as in _doSomethingDangerous(). This is meant to
> indicate to anyone using your module that they shouldn't use this
> function, at least not without having a good understanding of what it
> does.


There is, however, also the possibility of prefixing the method name
with '__'. The invokes 'name mangling', which makes it more difficult
(though not impossible, the idea is to avoid accidents) for the method
to be called from outside the class.

http://www.python.org/doc/2.5.2/tut/...00000000000000.

--RDM
 
Reply With Quote
 
MRAB
Guest
Posts: n/a
 
      12-11-2008
alex23 wrote:
> On Dec 12, 2:07 am, "Emanuele D'Arrigo" <(E-Mail Removed)> wrote:
>> I.e. if I have a class with two methods, doSomethingSafe() and
>> doSomethingDangerous(), is there a way to prevent another module from
>> executing doSomethingDangerous() but allow the execution of
>> doSomethingSafe()?
>>
>> My understanding is that in python this is not possible. Can you
>> confirm?

>
> Your understanding is correct.
>
> The Python convention is to prefix non-public methods/classes etc with
> an underscore, as in _doSomethingDangerous(). This is meant to
> indicate to anyone using your module that they shouldn't use this
> function, at least not without having a good understanding of what it
> does.
>

You could add a little bit of protection by always passing a certain
object into _doSomethingDangerous().

_guard = object()

def _doSomethingDangerous(g):
if g is not _guard:
raise Exception("Don't do that!")

That would at least stop accidental calls.
 
Reply With Quote
 
alex23
Guest
Posts: n/a
 
      12-11-2008
On Dec 12, 2:35*am, (E-Mail Removed) wrote:
> There is, however, also the possibility of prefixing the method name
> with '__'. *The invokes 'name mangling', which makes it more difficult
> (though not impossible, the idea is to avoid accidents) for the method
> to be called from outside the class.


That only works for methods, it has no effect on functions or classes
within modules:

module.py:
def __f(): pass

class __F(object):
def __f(): pass

>>> import module as m
>>> m.__f

<function __f at 0x00B80FB0>
>>> m.__F

<class 'module.__F'>
>>> f = m.__F()
>>> f.__f

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: '__F' object has no attribute '__f'
>>> f._F__f

<bound method __F.__f of <module.__F object at 0x00B89B30>>
 
Reply With Quote
 
alex23
Guest
Posts: n/a
 
      12-11-2008
On Dec 12, 3:22*am, alex23 <(E-Mail Removed)> wrote:
> On Dec 12, 2:35*am, (E-Mail Removed) wrote:
>
> > There is, however, also the possibility of prefixing the method name
> > with '__'. *The invokes 'name mangling', which makes it more difficult
> > (though not impossible, the idea is to avoid accidents) for the method
> > to be called from outside the class.

>
> That only works for methods, it has no effect on functions or classes
> within modules:


And of course -now- I realise that the OP was asking for protecting
methods. Please disregard my last post
 
Reply With Quote
 
r
Guest
Posts: n/a
 
      12-11-2008
> And of course -now- I realise that the OP was asking for protecting
> methods. Please disregard my last post


Alex23,
Are you telling me that you do not know how to YANK your own post? I
find that hard to believe.
 
Reply With Quote
 
Emanuele D'Arrigo
Guest
Posts: n/a
 
      12-11-2008
Thank you all for the confirmation and the suggestions (including the
tangential ones: I didn't know one could remove your his own posts!).

As much as I really like Python (which I've been using full-time only
for the past two months) I really wish it did have regular private/
protected/public methods.

I'm building an application that can be extended by the users and I
really wish there was a solid way to prevent them from accessing parts
of the application that they shouldn't access or to provide read-only
access. I.e. right now I'm working on the graphical client which
potentially could be rewritten entirely by the users. It is necessary
and perfectly reasonable for the client module to access some of the
objects to be represented graphically, but those objects shouldn't be
modifiable by it.

I now wonder, would developing the graphical client as an entirely
separate application, communicating with the server via the localhost
network interface and messages, solve the problem? Would it keep the
objects of the two applications (server/client) entirely separate?

Manu
 
Reply With Quote
 
Bruno Desthuilliers
Guest
Posts: n/a
 
      12-11-2008
Emanuele D'Arrigo a écrit :
> Sorry if I'm a bit thick here...
>
> can any of the esteemed participant in this noble newsgroup


Ain't that a bit over the border ?-)

> confirm
> that is not possible to prevent a python module's code from executing
> the methods of another module?
>
> I.e. if I have a class with two methods, doSomethingSafe() and
> doSomethingDangerous(), is there a way to prevent another module from
> executing doSomethingDangerous() but allow the execution of
> doSomethingSafe()?
>
> My understanding is that in python this is not possible. Can you
> confirm?


Well... If you really want a totally secure, absolute protection of
doSomethingDangerors, the only way is to run client code on a distinct
machine (implied : you have a client/server protocol).

Now the question is : do you _really_ need this level of security ?

If you want to "protect" your implementation methods (and other
attributes FWIW) from python developpers - IOW, to warn them they
_should_ not use them -, just prepend the name with a single leading
underscore. Yes, this is just a convention, but it's a very strong one.

If you want to protect some critical attributes (methods or whatever)
from _accidental_ redefinitions, prepend the name with two underscores.
This will invoke a name mangling mechanism such that what's internally
known as __my_attribute or __my_method is only externally (child classes
or any other code) as _MyClass__my_attribute (resp. _MyClass__my_method).

The next step would require using a lexical closure - IOW, define
do_something_dangerous *and* all the methods needing access to it in a
same function, and make this function return only "safe" functions, ie:

class MyClass(object):
def private_stuff_inside():
def do_something_dangerous(self, whatever):
# code here
def do_something_safe(self, yadda):
# code here
# NB : note the explicit passing of self here
foo = do_something_dangerous(self, yadda)
# more code here
def do_another_safe_thing(self, yadda):
# code here
bar = do_something_dangerous(self, yadda)
# more code here
return do_something_safe, do_another_safe_thing

do_something_safe, do_another_safe_thing = private_stuff_inside()
del private_stuff_inside()


This is not 100% safe, but accessing do_something_dangerous requires
some work, pretty good Python knowledge (and either access to the source
code or 'luck' or being very nasty, since there's no simple way to even
know do_something_dangerous exists). As far as I'm concerned, I'd say
that it's as safe as a Java so-called "private" method (which can always
be accessed thru reflexion FWIW...).

If that's still not enough, then *no* existing language will have
sufficiant protection (hint : how hard is it to get a crack for
Photoshop ?), and you're back to not even distributing the critical part
of your code - IOW, have the critical part only live on your own server.

A last word: unless do_something_dangerous *really* do something
"dangerous"[1] or business-critical[2] - in which cases you just don't
want to let _anyone_ access your code, not even in byte-compiled form -,
the two first solutions are good enough. FWIW and as far as I'm
concerned, I wouldn't even bother using the second one (name mangling)
unless I really have a pretty good reason to do so.


[1] like controlling a nuclear powerplant, posting all your porns to all
your addressbook, or such...

[2] IOW : it's your very secret killing algorithm that none of your
concurrents must learn or your out of business
 
Reply With Quote
 
Bruno Desthuilliers
Guest
Posts: n/a
 
      12-11-2008
Emanuele D'Arrigo a écrit :
> Thank you all for the confirmation and the suggestions (including the
> tangential ones: I didn't know one could remove your his own posts!).
>
> As much as I really like Python (which I've been using full-time only
> for the past two months) I really wish it did have regular private/
> protected/public methods.


What for ? What you need is a way to tell the client code what's part of
the interface and what's implementation detail. From experience (*years*
fo experience), no one in it's own mind will mess with implementation
unless he has a very compelling reason _and_ is willing to pay the price
("****, I broke everything... Ok, my fault.")

> I'm building an application that can be extended by the users and I
> really wish there was a solid way to prevent them from accessing parts
> of the application that they shouldn't access


In Python, "shouldn't access" is spelled with a single leading
underscore !-)

> or to provide read-only
> access. I.e. right now I'm working on the graphical client which
> potentially could be rewritten entirely by the users. It is necessary
> and perfectly reasonable for the client module to access some of the
> objects to be represented graphically, but those objects shouldn't be
> modifiable by it.


Why so ? At worst, they'll break everything. So what ? As long as they
mess with your implementation, they are responsible for what happens.
OTHO, someone may have a perfectly valid reason to rewrite parts (or
whole) of your GUI - and he'll just love you for not standing in the way.

> I now wonder, would developing the graphical client as an entirely
> separate application, communicating with the server via the localhost
> network interface and messages, solve the problem?


*which* problem ? Seriously ? What do you fear ? Extension code breaking
your app ? How is that *your* problem (I mean, as long as you
explicitely told the user what was part of the API and what wasn't ?).

What if your program was written in C, distributed only as compiled
machine code, and one of your users decided to make random edits in the
binary code ? Would you feel responsible ? *Nothing* in this world is
idiot-proof, so don't waste time trying to protect idiots from themselves.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
method def in method vs method def in block Kyung won Cheon Ruby 0 11-21-2008 08:48 AM
private data stashed in local/global execution context of PyEval_EvalCode disappears down the execution stack sndive@gmail.com Python 9 11-14-2007 10:31 PM
preventing Object#send from dispatching to a global method? Francis Hwang Ruby 15 07-09-2005 03:08 AM
HttpModule preventing execution of HttpHandlers MWells ASP .Net 3 01-12-2005 02:23 AM
preventing an entity-reference to be resolved (output method XML) Joris Gillis XML 3 10-11-2004 03:39 PM



Advertisments