all() is slow?

[Steven D'Aprano]

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