<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#ffffff">
Hey people,<br>
<br>
I'm writing an application in which we evaluate user-supplied Python
expressions.<br>
<br>
Sometimes, we want to do an equality test on the result of the
evaluation, eg:<br>
<br>
result = eval(...)<br>
if result == float('nan'):<br>
...<br>
<br>
If the result is a numpy array, then this raises a ValueError, since
the array equality operator returns a new numpy array, and the
coercion of this to a boolean for the if predicate then explicitly
raises. Presumably this is well-known? For us, it is undesirable.<br>
<br>
Am I right to understand that any code which might ever encounter a
numpy array therefore can never use an unguarded '<i>if x == y:</i>'
construction? Is my workaround really to replace every instance of
this with '<i>if not isinstance(x, numpy.array) and x==y:</i>' ?
This pains me, because otherwise this code would have no dependency
on numpy. (I can't just prepend 'isinstance(x, float)' because,
unlike the example above, we don't always know the type of the
equality RHS until runtime.)<br>
<br>
I can see that there's a pleasing symmetry to have all the array
arithmetic operators and comparisons operate in an element-wise
manner, but I think it's more important for __eq__ to follow it's
usual semantics of returning a boolean. I'd way prefer it if the
element-wise equality array generation was exposed as a different
method.<br>
<br>
Have I misunderstood the situation greatly? Thanks for any pointers
or suggestions.<br>
<br>
Jonathan<br>
<pre class="moz-signature" cols="72">--
Jonathan Hartley <a class="moz-txt-link-abbreviated" href="mailto:tartley@tartley.com">tartley@tartley.com</a> <a class="moz-txt-link-freetext" href="http://tartley.com">http://tartley.com</a>
Made of meat. +44 7737 062 225 twitter/skype: tartley
</pre>
</body>
</html>