On Fri, 01 Aug 2014 09:32:36 -0400, Roy Smith wrote: > In article <53db95e6$0$29986$c3e8da3$54964...@news.astraweb.com>, > Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > >> eval is almost never the right solution to any problem, and in the very >> few exceptions, it needs careful handling by an expert to ensure you're >> not introducing serious security bugs. > > Corollary to that rule: All the people who are smart enough to actually > understand how to use eval() safety, are also smart enough to know not > to use it.
... smart enough to know WHEN to use it (which is *rarely*). That's in production code, of course. There's nothing wrong with using eval in the interactive interpreter for quick and dirty exploration. But even then, I find that it's usually easier to write a line or two of Python code to process something than to try using eval. There are uses for eval (or exec), even if production code. See collections.namedtuple, doctest, and timeit, for example. In the first place, namedtuple takes extra care to sanitise the data being used. In the case of doctest and timeit, the whole point of them is to run trusted code. If you can't trust your own code that you're timing, what can you trust? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
