On 7/5/06, <b class="gmail_sendername">Greg Ewing</b> <<a href="mailto:greg.ewing@canterbury.ac.nz">greg.ewing@canterbury.ac.nz</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Michael Chermside wrote:<br><br>> That leaves the other problem: auxiliary means of accessing<br>> objects. There are things like gc.get_objects(). In the special<br>> case of file, which is a type that's also dangerous, there are
<br>> tricks like "object().__class__.__subclasses__()".<br><br>My approach to that would be to not provide access to<br>these kinds of things via attributes, but via builtin<br>functions. E.g there wouldn't be a __subclasses__
<br>attribute, but a subclasses() function. Then that<br>capability can be denied by not providing that<br>function.</blockquote><div><br><br>__subclasses__ is a function. And yes, if we go this route, that is what would happen most likely. The trick is figuring out any and all ways one can get to 'file' from a standard interpreter prompt.
<br><br>-Brett<br></div><br></div>