The point is that even though eval(raw_input()) is not a security threat, Alan's suggestion of myscript.py < some.txt might be. And even though the script written will not be a security issue, the *coding practice* that it teaches will lead to times when he does encounter that "tiny set of scenarios" in which the input for the script is potentially untrustworthy.
Even though the risk is perhaps minimal to you, it still needs to be made known. An analogy is the threat of mercury, in which breathing the vapors can cumulatively lead to brain damage. However, in most quantities that people are freaking out over are far too small to be a threat. Don't go overboard, and yet *know* what is out there. I'll give an example. The boss gives two employees the simple jobs: You~ write a function grapher And You~ write an input file that graphs the common mathematical functions so that it can be run in his~ function grapher. The first guy uses eval to parse the text file because of its power. All he has to do is graph, eval takes care of turning the lines from the text file into function objects. The second notices the first guy's approach and sees a chance to move up in the world. He writes his file to his advantage. The two put the final result together and show the boss. The computer destroys important data that the company has worked on (not protected by the OS) and the first guy is fired because *his* program deleted stuff. Ouch. Be aware of security risks, not infatuated by them. eval() is not a risk by itself, but getting used to using it could lead to problems. Subtle things will always bite you more than things of which you are completely aware. JS _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
