does lack of type declarations make Python unsafe?

[Brandon Corfman]

1) Why can't this issue be solved by making Python like Lisp/Dylan in 
this regard? Make type declarations/range limitations on variables an 
optional thing. Flexibility if you need it, safety later if you're 
concerned about it.

2) It also seems that the Python community wastes too much time on these 
explanations. A better answer (in my mind) would be to say that the 
Python environment is designed to make the development process far 
different than in a statically-typed language like C++.

Python is different because a) an interactive command prompt to allow 
instant evaluation/testing of return values encourages immediate 
testing, b) a unit testing framework encourage more long-term testing, 
and c) simple tuple-packing/unpacking allow multiple return values. All 
of these combine to make Python a development environment that 
encourages functional programming _and all development should be done 
this way_. If your functions at the lowest levels produce the results 
you are expecting, then you have confidence that the other higher-level 
functions built on top of them will produce the correct results as well.

This development process is vastly different than what a C++/Java 
programmer is used to, because even if they program functionally (and 
MOST do not), they rely on a debugger to test values. Although the 
Python environment has a debugger to make C++/Java programmers make the 
transition, I think new Python programmers should be steered toward 
using Python properly as soon as possible.

I think the problem is that a C++/Java programmer regards the Python 
command prompt as little more than a calculator or a place to type 
"prog.main()". I know I did at first.

Brandon



Peter Hansen wrote:
> David Abrahams wrote:
> 
>>I find that static typing makes a big difference for two things:
>>
>>  2. Refactoring.  Having a compiler which does some static checking
>>     allows me to make changes and use the compiler as a kind of
>>     "anchor" to pivot against.  It's easy to infer that certain
>>     changes will cause compiler errors in all the places where some
>>     corresponding change needs to be made.  When I do the same thing
>>     with Python I have to crawl through all the code to find the
>>     changes, and a really complete set of tests often take long
>>     enough to run that using the tests as a pivot point is
>>     impractical.
> 
> 
> I just went through a particularly straining session of refactoring
> yesterday.
> 
> I couldn't get my head around how to do what I wanted to do, but I
> kept bashing away at it, trying one thing, then another.  (One of
> my problems is that I'm still a little new at using generators, and
> I was trying to use a generator at the heart of the solution.)
> 
> At no time was I actually changing the interface to any of my
> functions, changing order of arguments or their types.
> 
> At no time did I actually encounter a syntax error or any other
> kind of error which stopped the code from running.
> 
> At no time did I make a single mistake which would have been
> caught by the compiler for a statically typed language.  I
> was on a roll I guess, typing accurately and not doing anything
> sloppy.
> 
> Nevertheless, I repeatedly injected logic errors and other such
> problems into the code as I tried to change its structure.
> 
> My tests helped me though.  I'd guess I had to back out of at
> least five different false directions, as one after another
> obscure test popped up, tapped me on the shoulder, and said,
> "Uh, excuse me?  What am I, chopped liver?  I need to pass too!"
> 
> Not proof of anything, or disproof, either, I suppose.  Just a
> little reflection on refactoring and the value of tests and
> static type checking.
> 
> -Peter