unpythonic use of property()?

[J Kenneth King]

Luis Zarrabeitia <kyrie at uh.cu> writes:

> On Monday 20 April 2009 11:29:19 am J Kenneth King wrote:
>> Changing the ID value would break things on the server, so I
>> wanted to write the interface class to respect those conventions.
>
> Then, take this opportunity fix the server and prevent it from breaking once 
> you change the ID, because:

Unfortunately it's not my server to fix. I can suggest a patch, but
that's it.

>
>> I'm well aware that if a developer really wanted to, they could get
>> around it no matter what I did, but I figure that if I at least make
>> it really difficult it will be obvious that they're really going into
>> dangerous territory.
>
> you will have to do it anyway.
>
> I think it's great, for you, that the language you are using makes it so 
> extremely easy to bypass almost any access restriction that you may put in 
> the data sent to your clients. That means that you won't be overconfident, 
> that you are forced to make sound decisions from the beginning, and that you 
> won't be trusting that your clients will be well behaved (even with very 
> strong enforcement of data hiding, a malicious client could forge the 
> connection).
>
> Then, when the server is safe from user data, by all means go and make sure 
> that the clients (and even the server!) will complain as loudly as possible 
> if they want to break encapsulation.

Well, really all I'm doing is writing a light framework around xmlrpclib.

The design allows me to keep this kind of exception highly localized,
so its not really a huge practical issue.

The problem I had was that I found two approaches to the same problem
that appeared to be pedantic in difference.

However, you are right of course -- logically the server should
protect against this vulnerability itself instead of the
implementation using my framework.