does lack of type declarations make Python unsafe?

[David Abrahams]

Alexander Schmolck <a.schmolck at gmx.net> writes:

> jjl at pobox.com (John J. Lee) writes:
>
>> David Abrahams <dave at boost-consulting.com> writes:
>> 
>> > Brandon Corfman <bcorfman at amsaa.army.mil> writes:
>> > 
>> > > 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.
>> > 
>> > Ever try to write a class with more than 2 methods at the
>> > command-line?  After screwing it up several times I always revert to
>> > emacs <wink>.
>> 
>> I agree with this.  I don't know what all the fuss is about with the
>> interactive prompt. 
>
> Maybe you're just not using it in the most effective manner (possibly because
> your problems don't profit that much from it).

Don't get me wrong, I love the interactive command-prompt.  I mostly
use it to explore the language:

   >>> help(whatever)

and the ability to test ideas with types, descriptors, and metaclasses
which actually need to be coded in C++ (though the limit of complexity
of what I can try without wasting my time retyping whole class
definitions is *very* low at the prompt), and to discover the actual
behaviors hidden in underdocumented parts of the language, is
invaluable.

Anything that has more "heft" to it I need a good record of anyway.
At the very least I'll use the command-prompt from within emacs ;-)

> What good IDEs do you have in mind? The only ones I've ever seen are
> for dynamically typed languages such as smalltalk.
>
> If you essentially just emulate write-compile-run cycles with python
> you might not notice that much of a difference to a statically typed
> mainstream language such as C++ or Java.
>
> But believe me, there is a *huge* difference between being for
> example able to interactively explore and modify some complicated
> data or code and not being able to do so.

For example?  Always willing to learn how to use Python more effectively.

>> Maybe only me and David make lots of mistakes at the interactive prompt ;-)
>
> The idea is not to write the bulk of your code in an interactive
> prompt -- the idea is to write the bulk of your code with your
> editor/IDE whatever and then have it evaluated in a running
> interactive session upon keypress. If something goes wrong the
> debugger should automatically pop up and go to the matching source
> code line. You can than look at and interact with live objects in
> the debugging session to find out what's going wrong, fix the piece
> of code in your editor and evaluate it (and not the whole program)
> again. 

Has someone really straightened out the situation with Python
debuggers?  Last time I looked there was no JIT debugging, and no way
to set a conditional breakpoint in a long-running test without waiting
forever as Python calls the debugger hook on every instruction (or
statement, I forget).  Last time I talked to Guido about fixing the
latter problem he said "you're using Python the wrong way".  The
lesson I took away from it was: hold your nose and modify the code
(which often is from a 3rd party) with debugging checks and print
statements if you want to figure out what's going on.

I'd love it if things had gotten better.  Did I miss some improvement?

> If you want to see or edit the source code for some object it
> only takes a single short command. Writing test code also becomes
> much more fun.

Err, isn't there a longstanding issue with getting modules to be
reloaded appropriately and all cross-references resolved when you do
this?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com