Thanks to both of you. In this particular case, the main use of eval() was only for 2 calls, which were essentially hard-coded (you could see the calls to summarize_game in my code). I was looking for a more general solution to what I was trying to do, but I don't need it for this project. Still, this has been an informative conversation.
On Sat, Jan 4, 2014 at 12:56 AM, Steven D'Aprano <st...@pearwood.info>wrote: > On Sat, Jan 04, 2014 at 12:32:19AM -0500, Keith Winston wrote: > > On Fri, Jan 3, 2014 at 11:59 PM, Steven D'Aprano <st...@pearwood.info > >wrote: > > > > > thelist = vars()[name] > > > > > > I see: vars() certainly looks less dangerous than eval(), but I'm > guessing > > that's still smelly code? I hadn't known about vars() or I probably would > > have used it. > > Yes, it's still a bit smelly: but only a bit, since while "direct" code > is the idea, sometimes the only way to do things is with one (or two) > layers of indirection. > > Code should (as a general rule) not rely on, or be affected by, the name > of the variable. Functions which inspect the running environment (i.e. > peek deep inside the interpreter) or use eval or other techniques to > operate "behind the scenes" on *names* rather than values can often lead > to confusing code. As debugging tools, they're useful. Putting such > functionality inside normal everyday programs is a code smell. > > > -- > Steven > _______________________________________________ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > https://mail.python.org/mailman/listinfo/tutor > -- Keith
_______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
