does lack of type declarations make Python unsafe?

[Alexander Schmolck]

beliavsky at aol.com writes:

> David Abrahams <dave at boost-consulting.com> wrote in message news:<uwufmko7g.fsf at boost-consulting.com>...
> 
> SNIP
> 
> > I find that static typing makes a big difference for two things:
> > 
> >   1. Readability.  It really helps to have names introduced with a
> >      type or a type constraint which expresses what kind of thing they
> >      are.  This is especially true when I am coming back to code after
> >      a long time or reading someone else's work.  Attaching that
> >      information to the name directly is odious, though, and leads to
> >      abominations like hungarian notation.
> 
> I strongly agree with this. For numerical work, especially numerical
> linear algebra, having the compiler check types and the # of
> dimensions can detect many errors.

Have you compared developing with (i)python/Numeric to Fortran (I am not
saying you haven't, but I'd be curious to know)? If so, did you develop mainly
in a single interactive session or did you use edit/run cycles?

> 
> The beginning of the following Fortran 95 subroutine, for example,
> provides useful information both to the compiler and to a programmer
> trying to understand what it does:
> 
> subroutine solve_lsq_svd_rmse(aa,bb,xx,rmse,ierr)
> ! solve a set of least-squares linear equations and compute the rmse
> real     , intent(in)   :: aa(:,:) ! matrix of independent variables
> real     , intent(in)   :: bb(:)   ! vector of dependent variable
> real     , intent(out)  :: xx(:)   ! solution of least-squares problem
> real     , intent(out)  :: rmse    ! rmse of regression
> integer  , intent(out)  :: ierr    ! error flag


def solve_lsq_svd_rmse(aa,bb):
    """Solve a set of least-squares linear equations and compute the rmse.

    Parameters: 
      - `aa` matrix of independent variables 
      - `bb` vector of dependent variable

    Returns: A tuple consisting of the solution of the least squares problem
      and the rmse of regression.

    """
    aa, bb = asarray(aa), asarray(bb)
    assert rank(aa) == 2 and rank(bb) == 1 # likely to be superfluous
    [...]


> 
> In Python, to ensure that aa is a 2-D array and that bb and xx are 1-D
> arrays, you need to write some checking code, which will not be as
> clear as the above declarations IMO.  

Well, tastes might differ but I'd rather read the python version (chances are
I wouldn't even have to read it -- ``help(solve_lsq_svd_rmse)`` in the
interpreter would tell me what I need to know about it, provided it comes as
part of a respectable libarary and is likely to work).

> Even if you do this, the errors will be caught at run time, not compile
> time.

Typing the following into the interactive shell:

>>> 9 + "f"

will also produce a run-time rather than a compile time error (as it would in
say, Pascal -- where'd you'd have to write boilerplate code and compile it
first). Which form of feedback in this case you think is quicker and more
effective?

If you write and test your code interactively (of course also writing proper
unit tests) runtime errors provide in many cases better and more immediate
feedback than compiler errors in lesser languages such as C, especially since
the C catches only very few errors at compile time and gives about *zero*
error feedback at runtime (thus, the 9 + "f" example above (plus the
appropriate boilerplate code) compiles fine and without warnings under at
least one C compile I tried).


> 
> (Regardless of the language, you need to check that the # of rows in
> aa equals the # of elements in bb. This usually must be done at run
> time.)

No, you don't need to check everything regardless of language. Obsessive
compile time checks are so important in primitive languages like C(++) Fortran
because they fail catastrophically but often silently if something goes wrong.
A dynamically typed high level language like python typically won't. In most
cases if the number of rows doesn't match the number of elements, chances are
you'll get an appropriate error message, the same if you passed an argument of
the wrong type. Plus, chances are the statically typed version will be
artificially constrained in the input types it can deal with.

'as