exceptions

Hung Jung Lu hungjunglu at yahoo.com
Tue Jun 1 22:21:48 CEST 2004


Alexander Schmolck <a.schmolck at gmx.net> wrote:
> Did this language support working interactively? If so I'd be pretty surprised
> to hear that no one found it useful to be able to manually fix things and
> continue execution; not being able to do so is presumably my number one gripe
> with python [1] -- it annoys me no end if I need to start an expensive
> computation from scratch because some trivial and easily fixable problem
> occured towards the end of the computation (sometimes it is possible to
> salvage stuff by hand by pickling things from the appropriate post-mortem
> frame, but I'd *much* prefer being able to say: foo=some_value; resume).

The edit-and-continue feature is also standard in the Microsoft world.
Visual C++ and Visual Basic 6.0 all have this feature. (VB.NET does
not, but they are implementing it for the version 2005 aka Visual
Studio Whidbey.) Edit-and-continue is useful debugging tool,
especially if the initial-state setup is expensive.

Python is good, but not good enough in many areas.

> Footnotes: 
> [1]  Number 2 would be the stupid try: finally: idiom which also seems to
>      screw up tracebacks (which has occasionally led me to get rid of them
>      completely while debugging -- surely not a good thinge). My other gripes
>      are again related to python's limitations for interactive software
>      development -- I rather like python, but I really wish it did that 
>      better.

There are a few lessons learnt from younger programming languages,
like Io. One lesson is that you really would like to avoid rigid
statement syntax. In the example of the original topic of this thread,
you cannot intercept/override exception handling mechanism because the
try:...except:... block is not a function. Similar situations happen
with issues regarding aspect-oriented programming. In a language like
Io, everything is a method that send message to an object. Even
If(...) statements are methods, as well as loops. The advantage is you
can intercept things at your heart's content. In comparison, Python's
exception handling is not interceptible, because exception handling is
hard-coded in syntax.

It does not mean all hope is lost in Python. But it does mean that
instead of using the raise... statement in Python, you need to call a
function/method instead. You can then intercept at that level: either
by actually throwing an exception, or by redirecting it to some user
intervention funtion, or by totally ignoring it (like using a 'pass'
statement.)

Interactive programming with features like edit-and-continue still has
room to grow (most edit-and-continue features are not transactional,
that is, you cannot revert changes easily.) But in my opinion that's
an arena for prototype-based languages, and down the line, for
reversible-computing languages. Frankly, theoretically it is possible
to have a development environment where you never need to restart your
program (for non-real-time applications.)

As for Python's interactive programming, I've done some experiment
before. It's not totally impossible. It's a bit uncomfortable. Python
does have module reload and weakref. When you use these tools
properly, you can achieve a high degree of non-stop programming. It
does not come as part of the language per-se. You need to build up
some tools yourself first. But after that, you can achieve non-stop
programming, more-or-less. After all, Zope is a living example of a
Python application where you can program a lot of things, without
shutting down the server.

regards,

Hung Jung



More information about the Python-list mailing list