Accessors in Python (getters and setters)

[Ed Jensen]

Diez B. Roggisch <deets at nospam.web.de> wrote:
> Which puts us to the next question: the sealing itself doesn't do 
> anything to restrict the code, the SecurityManager does. Which AFAIK is 
> something hooked into the VM. Now, I'm not on sure grounds here on how 
> to altere its behaviour, but I'd say if we're talking me working on a 
> secure application that introduces its own SecurityManager, I'm still 
> the one in control. I could use your lib, turn off privacy, and fiddle 
> around.
> 
> If things were the other way round, and I'd have to work in a restricted 
> context, it actually might be that someone restricted private access 
> (because he owns the VM!). But then - he'd also be able to forbid 
> threading or file access or all kinds of things that I'd otherwise be 
> used to work with which will suddenly make my code burst in flames.
> 
> And if we are honest: the most problematic cases of abused code aren't 
> the ones of strangers exploiting your code, but instead your fellow 
> coders at the other department. Which most probably means that they 
> aren't restrained by security management anyway.
> 
> To summarize: it might be possible to jump through a few hoops to 
> increase the security. But in 99.9% of cases this doesn't happen, as it 
> would increase complexity by orders of magnitude - for a comparatively 
> small gain (talking about private declarations. The sandbox-restrictions 
> of Java for running applets certainly are worth it).

Interesting stuff!  And thanks for the link from your earlier post.

Where I work, this little discovery will actually help us stop jumping
through some hoops we've been jumping through to unit test private
methods.

It also gives us more to think about since we had been assuming
private could not be circumvented.

Thanks Diez.  :)