On Tue, 2005-05-03 at 07:44, Nadav Horesh wrote:
>>> import numarray as N
> >>> a = N.array((2.3, 4.3))
> >>> N.__version__
> '1.3.1'
> >>> help(a.stddev)
> 
> Traceback (most recent call last):
>   File "<pyshell#11>", line 1, in -toplevel-
>     help(a.stddev)
>   File "/usr/local/lib/python2.4/site.py", line 328,
in __call__
>     return pydoc.help(*args, **kwds)
>   File "/usr/local/lib/python2.4/pydoc.py", line
1647, in __call__
>     self.help(request)
>   File "/usr/local/lib/python2.4/pydoc.py", line
1691, in help
>     else: doc(request, 'Help on %s:')
>   File "/usr/local/lib/python2.4/pydoc.py", line
1475, in doc
>     pager(title % desc + '\n\n' +
text.document(object, name))
>   File "/usr/local/lib/python2.4/pydoc.py", line 297,
in document
>     if inspect.isroutine(object): return
self.docroutine(*args)
>   File "/usr/local/lib/python2.4/pydoc.py", line
1226, in docroutine
>     if object.im_self:
>   File
"/usr/local/lib/python2.4/site-packages/numarray/generic.py",
> line 537, in __nonzero__
>     raise RuntimeError("An array doesn't make sense
as a truth value. 
> Use any(a) or all(a).")
> RuntimeError: An array doesn't make sense as a truth
value.  Use any(a)
> or all(a).
> >>> help(a.sum)
> 
> 
In my opinion,  this is a limitation (bug is maybe too
strong) of pydoc,  in that pydoc's docroutine method
requires that an object be evaluable as a truth value
and that the result be True.   I think that's a common,
but wrong, idiom.

I believe it's widely recognized that array's don't
make much sense as truth values because it leads to
code like this:

>>> a = array(5);  b = array(8)
>>> a & b
array(0)
>>> if a & b:
...    print "foo!"
foo!

Numeric expressions like the above implicitly mean
any(a & b) and appear to work but really contain subtle
bugs.

Hence,  in numarray and Numeric3 (now or eventually),
the exception:

>>> if a & b:
... 	print "foo!"
... 
Traceback (most recent call last):
...
RuntimeError: An array doesn't make sense as a truth
value.  Use any(a) or all(a).

I think the pydoc docroutine() code should be changed
to read:

if object.im_self is not None:

and that particular limitation will be removed.  I
submitted a patch.

Regards,
Todd

Logged In: YES 
user_id=320512

The attached patch fixed my immediate problem but is
untested against the Python test suites.  I did not do a
careful analysis for other uses of the "if o:" idiom but
noted that there are many of which I'm fixing two.  I only
have anonymous access to Python CVS and it is unusable.

Thanks for the patch, fixed in rev. 54365, 54366 (2.5).