Why Python?

[Gerhard Häring]

Re: Why Python?

Robert M. Emmons wrote:[color=blue]
> IMHO the whole reason C/C++ has sophisticated debugging tools is
> that code debugging in C is a nightmare.[/color]

That's my opinion as well.

One debugging feature that Python doesn't support is "edit-while-debugging" (edit
the function/method) you just debug, something which is possible in VB and VC6,
for example) I think it'd not be *that* hard implementing it. Maybe a Python IDE
vendor will implement it some day.

-- Gerhard

[Wayne Folta]

Re: Why Python?

everything

But you were expecting that.

How about

everything in every way in all situations

The bottom line is python is a clear, powerful language that has a
great culture. You have a choice:

1. You want to learn the "perfect" language for each project at hand.
Even if you're good at learning new languages -- as I think I am --
it's still going to take you a while to be idiomatic in the language
instead of, say, programming perl in python.

Not to mention that finding the "perfect" language can take quite some
time for each project. You'll have language advocates on each side of
the issue. Is this project a natural fit for lisp? Oh, no, ruby's much
more practical for this. Yes, but foobar has a package for doing
exactly what you want. Blah, blah...

2. Learn a general-purpose language that can be easily used with many
different paradigms (OO, functional, etc), has a good library set
(network, math, etc), and has a flexible culture. This language should
be reasonably well-known so you can find it widely, can find books on
it, etc.

Some might say that perl 6 will be the epitome of #2, though my opinion
is that perl will manage to implement #1 in a single language.

If you want to go with option #2, python's at the top of the list, in
my opinion.

(Actually, there is a #3: you want to be highly marketable. Depending
on where you want to work, the language de jour is likely to be C++,
Java, or Visual Basic.)

[Bob Ippolito]

Re: Why Python?

On 2004-03-01 09:02:01 -0500, claird@lairds.c om (Cameron Laird) said:
[color=blue]
> In article <1045c7gfn9ipj3 8@corp.supernew s.com>,
> Robert M. Emmons <RobMEmmons@cs. com> wrote:
> .
> [apt comments]
> .
> .[color=green]
>> What's not good in python:
>>
>> * If speed is more important than coding time use C/C++ instead.
>> * If you want to obscruate your code maybe a compiled langague is better.
>>
>> Rob[/color]
>
> Note the availability of pyobfuscate <URL:
> http://www.lysator.liu.se/~astrand/p...s/pyobfuscate/ >.
>
> Myself, in the absence of more details, I advise people for
> whom speed is important to work in Python--but be prepared
> to combine it with C coding (or even assembler! I've been
> experimenting lately ...).[/color]

One thing to note is that it is *reasonable* to combine C, C++,
assembly, etc with Python because the Python API is consistent and
understandable, and doesn't require a confusing "precompile r" (though,
Pyrex is a great one).

-bob

[Jacek Generowicz]

Re: Why Python?

Gerhard Häring <gh@ghaering.de > writes:
[color=blue]
> One debugging feature that Python doesn't support is
> "edit-while-debugging" (edit the function/method) you just debug,
> something which is possible in VB and VC6, for example)[/color]

Sorry ... what do you mean by "edit while debugging" ?

Something like XCode's "fix-n-continue" ?

In other words the ability to redefine a function in a running program
(possibly even before the stack has been unwound after an error (or
breakpoint) was encountered) ?

[Something which has been an inherent part of the language in many
members of the Lisp family for decades, BTW]

If you forget about not unwinding the stack, Python certainly supports
this.

Now, how would one prevent stack unwiding when an exception is raised
.... in order to allow the user to inspect the stack frames navigate
them, redifine any functions, and then allow continuation?

[I guess I could find the answer in the pdb source.]

[Michael Geary]

Re: Why Python?

> Gerhard Häring wrote:[color=blue][color=green]
> > One debugging feature that Python doesn't support is
> > "edit-while-debugging" (edit the function/method) you
> > just debug, something which is possible in VB and VC6,
> > for example)[/color][/color]

Jacek Generowicz wrote:[color=blue]
> Sorry ... what do you mean by "edit while debugging" ?[/color]

You can set a breakpoint in a function, and while stopped at that breakpoint
you can edit the code in that same function. Then, you can continue
execution and it will execute your new code.

As much as I dislike C++, Visual Studio's Edit and Continue feature is a
huge benefit. I often write the skeleton of a function, start the program
and trace into the function, and then write the code right there with the
program running, with live data to test while coding.

You can also change the execution pointer while stopped at a breakpoint. So
you can write some code and test it, and then if you want to change the code
and test it again, just move the execution pointer back to the beginning of
your code.

-Mike

[Hung Jung Lu]

Re: Why Python?

Gerhard Häring <gh@ghaering.de > wrote in message news:<mailman.2 1.1078156622.22 701.python-list@python.org >...[color=blue]
>
> One debugging feature that Python doesn't support is "edit-while-debugging" (edit
> the function/method) you just debug, something which is possible in VB and VC6,
> for example) I think it'd not be *that* hard implementing it. Maybe a Python IDE
> vendor will implement it some day.
>
> -- Gerhard[/color]

I have used Python's reload and weakref to build classes and have
succeeded in develop simple UI programs in a non-stop fasion, i.e.,
you build your application while it is running, without needing to
shut it down and restart (theoretically. ) It's like open-heart
surgery.

I believe VB and VC6's "edit-and-continue" does not roll back states
(neither does my Python program), which kind of makes them less
useful. I mean, you cannot use this feature to build up an application
truly in a continous, non-stop fashion. If for some reason you have
modified some states, you will have to restore them manually, before
you continue with the new debugged code.

A true "edit-and-continue" is somewhat related to two areas of
computing that I am aware of: (a) reversable computing, (b)
prototype-based programming languages. The first one is highly
theoretical, and claims that if everything is done right, our
computers will dissipate zero heat due to the conservation of entropy.
Reversing execution effects in these software/hardware combos is
always possible. The second one allows the programmer to easily build
surrogate objects, and commit the changes only at the end. (This will
dissipate heat with current hardware/software configurations. )
Moreover, surrogates can be built as onion skins, so even if you
commit the changes at the outter layers, you can still roll-back at
the inner layer later. Prototype-based languages thus may enjoy a
territory that common class-based OOP language do not. Theoretically
it's possible to build an application in a non-stop fashion this way,
but of course there are constraints from memory size and
non-compliance from existing libraries written in traditional
languages that do not support roll-back.

regards,

Hung Jung