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;">
Brett Cannon wrote:<br><br>> Armin in an email said that he thought it was<br>> a losing battle to try to hide 'file' from an interpreter.<br><br>And I would change file() so that it didn't open<br>files. Then it would be harmless for code to have
<br>access to the file class.</blockquote><div><br><br>Right, that is essentially what I proposed initially with the whole crippling idea.<br><br>What the capabilities supporters are saying is that if we go that route we will be constantly finding objects that require similar crippling. It will degenerate into this constant chasing of our tail to plug security holes where an object that we did not account for leaked out and wreaked havoc. What they are saying is that if we harden Python so that references don't get out without us knowing about it we won't have this run-around.
<br><br>But then my question has been what makes us trying to cripple objects any less of a run-around then finding new ways to get at references of 'file' or any other object? I have been suggesting the former requires less running around than the latter. That is why I have asked that people see how many ways they can come up with to get to 'file' from a standard interpreter prompt so we can gauge how bad hiding references might be.
<br> <br>-Brett</div></div>