On 03 Oct 2005 14:45:43 -0700, Paul Rubin <http://[EMAIL PROTECTED]> wrote:
>Mike Meyer <[EMAIL PROTECTED]> writes: >> > If you have a java class instance with a private member that's (say) a >> > network socket to a special port, access to the port is controlled >> > entirely by that class. >> >> Are you sure? My understanding was that Java's introspection mechanism >> could be used to access private variables. > >Right, I should have been more specific, if I understand correctly, >there are some JVM settings that turn that on and off (I'm not any >kind of expert on this). For sandbox applets, it's turned off, for >example. This came up in a huge discussion thread on sci.crypt a few >months ago. Apparently the default is for it to be turned on, to the >surprise and disappointment of some: > > http://groups.google.com/group/sci.crypt/msg/23edaf95e9978a8d > >> A couple of other things to think about: >> Are you sure you want to use the C++ model for privilege separation? > >I'm not sure what you mean by the C++ model. If you mean the Java >model, as I keep saying, applet sandbox security relies on it, so it >may not be perfect but it's not THAT bad. Using it routinely in >normal applications would be a big improvement over what we do now. >High-security applications (financial, military, etc.) would still >need special measures. > >> C++'s design doesn't exactly inspire confidence in me. > >Me neither, "C++ is to C as lung cancer is to lung". > >> Finally, another hole to fix/convention to follow to make this work >> properly in Python. This one is particularly pernicious, as it allows >> code that doesn't reference your class at all to violate the private >> variables. Anyone can dynamically add methods to an instance, the >> class it belongs to, or to a superclass of that class. > >Yes, Python isn't even type-safe any more: > > class A(object): pass > class B(object): pass > a = A() > print type(a) > a.__class__ = B > print type(a) # oops > >IMHO that "feature" you describe is quite inessential in Python. The >correct way to override or extend the operations on a class is to >subclass it. I can't think of a single place where I've seen Python >code legitimately go changing operations by jamming stuff into the >class object. I'd consider the stdlib's socket.py to be illegitimate >and it cost me a couple of hours of debugging one night: > > http://groups.google.com/group/comp.lang.python/msg/c9849013e37c995b > >and even that is only messing with specific instances, not classes. >Make sure to have a barf bag handy if you look at the socket.py code. >I really should open a sf bug about it. But a class definition is just a syntactic sugar way to associate functions with certain automatic method-binding operations for its instances, invoked by other syntactic sugar. But you can do it without modifying the class itself. E.g., >>> add5 = (lambda self, x: self+x).__get__(5, type(5)) >>> add5 <bound method int.<lambda> of 5> >>> add5(10) 15 I can't stuff the method on type(5) since it's built in, >>> type(5).add5 = (lambda self, x: self+x).__get__(5, type(5)) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: can't set attributes of built-in/extension type 'int' but that doesn't stop forming a bound method ;-) for a better name than <lambda> you can always fix it up ;-) >>> add5.im_func.func_name = 'add5' >>> add5 <bound method int.add5 of 5> Regards, Bengt Richter -- http://mail.python.org/mailman/listinfo/python-list
