Python complaints

[Fred L. Drake, Jr.]

Charles Boncelet writes:
 > If I call a function with the wrong type arguments, I (usually) get
 > a failure of one sort or another. E.g., len(5), math.sin([1,2,3]) 
 > both fail, although I think both should succeed. Numeric.sin([1,2,3]) 
 > succeeds.

Charles,
  Unless a programmer is specifically intersted in numeric processing, 
why should math.sin() work on a list?  In the general case, there's
*nothing* to indicate that a list should be processed as a
mathematical construct.  This is a specialized interpretation, and it
makes sense to use a specialized function to handle it (which is an
important aspect of why NumPy exists).

 > What kind of number is allowed?  Can x be an integer, a float, complex,
 > long, hex?  There is no way to know, without doing the experiment.
 > BTW, experimentation indicates that it fails if x is complex and works
 > for the others. sin seems to be promoting its argument to a float and
 > taking the sine.  However, sin(complex) is a perfectly good mathematical
 > operation.  It should work.

  The issue with complex numbers and the math module is real, and the
documentation isn't terribly clear.  There is some discussion in the
documentation for the cmath module regarding the behavior; I've added
a bit of explanation to the math module documentation as well to make
it easier to find the explanation.  This will appear in the next
documentation release.

 > If Python is a typeless language, then shouldn't all functions make a
 > reasonable effort at promotion to try to do something reasonable? (E.g.,
 > the Numeric ufuncs generally do this correctly.)

  What is reasonable is in many cases domain specific, as with the
case of sin([1, 2, 3]).  That's why there are at least three versions
available; you can choose the one that makes sense for what you're
doing.

 > If Python is a typed language, shouldn't we be able to determine 
 > what types are allowed as arguments and returned from functions 
 > without experimentation (and reverse engineering from the source code)?

  As someone else pointed out using the buffer object as an example,
this doesn't always make sense.  In some cases it does, and there are
definately cases in which the documentation can be improved.  (For the 
later, I always welcome specific suggestions and patches; send email
python-docs at python.org!)  Where it doesn't make sense, the issues
range from the introduction of new types that can be interchanged with 
existing types in interesting way (like the buffer type) to
implementing algorithms that accept a high degree of polymorphism from 
the input objects.  For Python, that's a strength we don't want to
lose!


  -Fred

--
Fred L. Drake, Jr.	     <fdrake at acm.org>
Corporation for National Research Initiatives