On Wed, 09 Nov 2011 20:26:56 -0500, Devin Jeanpierre wrote: >> Neither am I. I am less suspicious based on a reputation. Raymond is a >> well-known, trusted senior Python developer who knows what he is doing. > > I don't really know anything about him or why people respect him, so I > have no reason to share your faith.
That's fine. I don't expect you to take my word on it (and why should you, I could be an idiot or a sock-puppet), but you could always try googling for "Raymond Hettinger python" and see what comes up. He is not some fly-by Python coder who snuck some dubious n00b code into the standard library when no-one was looking :) The mere fact that it was accepted into the standard library should tell you that core Python developers consider it an acceptable technique. That's not to say the technique is uncontroversial. But there are still people who dislike "x if flag else y" and @decorator syntax -- controversy, in and of itself, isn't necessarily a reason to avoid certain idioms. Are you familiar with the idea of "code smell"? http://www.codinghorror.com/blog/2006/05/code-smells.html http://www.joelonsoftware.com/articles/Wrong.html I would agree that the use of exec is a code smell. But that doesn't mean it is wrong or bad, merely that it needs a second look before accepting it. There's a world of difference between "You MUST NOT use exec" and "You SHOULD NOT use exec". See RFC 2119 if you are unclear on the difference: http://www.ietf.org/rfc/rfc2119.txt >> It reads fine, and the justification is perfectly valid. > > Well. It reads fine in a certain sense, in that I can figure out what's > going on (although I have some troubles figuring out why the heck > certain things are in the code). The issue is that what's going on is > otherworldly: this is not a Python pattern, this is not a normal > approach. To me, that means it does not read fine. There's nothing inside the template being exec'ed that couldn't be found in non-exec code. So if you're having trouble figuring out parts of the code, the presence of the exec is not the problem. Having said that, dynamic code generation is well known for often being harder to read than "ordinary" code. But then, pointers are hard too. > The use of exec also results in (seemingly) arbitrary constraints on the > input. Like, why can't "--" be a name? Because exec? Is there some other > reason? Because Python doesn't allow "--" to be an attribute name, and so namedtuple doesn't let you try: t = namedtuple("T", "foo -- bar")(1, 2, 3) print(t.foo) print(t.--) print(t.bar) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
