exceptions

[Zunbeltz Izaola]

Hi,

I've the following problem with try/exception.
I've a try block that will raise some exceptions.
I want the program to ignore this exceptions completely.
Is it possible?

Thanks in advance

Zunbeltz

--
Zunbeltz Izaola Azkona | wmbizazz at lg dot ehu
dotes
Materia Kondentsatuaren Fisika Saila |
Zientzia eta Teknologia Fakultatea | Phone: [phone]
Euskal Herriko Unibertsitatea |
PK 644 | Fax: [phone]
48080 Bilbo (SPAIN) |

[Peter Hansen]

Zunbeltz Izaola wrote:

I've the following problem with try/exception.
I've a try block that will raise some exceptions.
I want the program to ignore this exceptions completely.
Is it possible?

In the following, all exceptions will be ignored:

try:
# something that raises exceptions
except:
pass

This is definitely *not* a recommended way to write software,
however. You should really understand what you are doing before
writing code this way.

-Peter

[Brian Gough]

Zunbeltz Izaola <zu******@wm.lc.ehu.es.XXX> writes:

I've the following problem with try/exception.
I've a try block that will raise some exceptions.
I want the program to ignore this exceptions completely.
Is it possible?

You can use an empty "except:" to catch all exceptions and ignore them,

try:
# your code
except:
pass

See the Python tutorial or language reference manual for details.

--
Brian Gough

Network Theory Ltd,
Publishing the Python Manuals --- http://www.network-theory.co.uk/

[Zunbeltz Izaola]

Peter Hansen <pe***@engcorp.com> writes:

Zunbeltz Izaola wrote:

I've the following problem with try/exception.
I've a try block that will raise some exceptions.
I want the program to ignore this exceptions completely. Is it
possible?
In the following, all exceptions will be ignored:

try:
# something that raises exceptions
except:
pass

I've trid this, but the problem is that this finished the try block.
I want to continue executing the try block from the point the
exception was raised.
This is definitely *not* a recommended way to write software,
however. You should really understand what you are doing before
writing code this way.

I know. I need this feature for testing. I will desable it later.

Zunbeltz
-Peter

--
Zunbeltz Izaola Azkona | wmbizazz at lg dot ehu
dotes
Materia Kondentsatuaren Fisika Saila |
Zientzia eta Teknologia Fakultatea | Phone: [phone]
Euskal Herriko Unibertsitatea |
PK 644 | Fax: [phone]
48080 Bilbo (SPAIN) |

[Jeff Epler]

Use "pass" as the body of the "except:" block. For example:

def put(s, i, j):
"""Store j at s[i], or do nothing if s is not that long"""
try:
s[i] = j
except IndexError:
pass

l = [1, 2, 3]
put(l, 1, "hi")
put(l, 4, "bye")
l

[1, 'hi', 3]

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAuyCpJd01MZaTXX0RAgFJAJ4sSYM9XKWuzJk9vzXGMg nU2EhfZgCfR70/
YjRBsk9yMptdSNWPodl46vQ=
=hQG9
-----END PGP SIGNATURE-----

[Peter Hansen]

Zunbeltz Izaola wrote:

Peter Hansen <pe***@engcorp.com> writes:

Zunbeltz Izaola wrote:

I've the following problem with try/exception.
I've a try block that will raise some exceptions.
I want the program to ignore this exceptions completely. Is it
possible?

In the following, all exceptions will be ignored:

try:
# something that raises exceptions
except:
pass

I've trid this, but the problem is that this finished the try block.
I want to continue executing the try block from the point the
exception was raised.

Not possible except, perhaps, with a significant amount of
working involving sys.settrace(). I think you need to find
another way to solve the problem.

What you are trying to do is not something that other people
who do unit testing seem to have to do. Why do you think
you need to actually *disable* exceptions entirely in order
to test this code? Perhaps the code needs to be restructured?

-Peter

[Zunbeltz Izaola]

Peter Hansen <pe***@engcorp.com> writes:

Zunbeltz Izaola wrote:

Peter Hansen <pe***@engcorp.com> writes:

Zunbeltz Izaola wrote:

I've the following problem with try/exception.
I've a try block that will raise some exceptions.
I want the program to ignore this exceptions completely. Is it
possible?

In the following, all exceptions will be ignored:

try:
# something that raises exceptions
except:
pass I've trid this, but the problem is that this finished the try block.
I want to continue executing the try block from the point the
exception was raised.

Not possible except, perhaps, with a significant amount of
working involving sys.settrace(). I think you need to find
another way to solve the problem.

What you are trying to do is not something that other people
who do unit testing seem to have to do. Why do you think
you need to actually *disable* exceptions entirely in order
to test this code? Perhaps the code needs to be restructured?

Possibly the code should be restructered, and re-designed; there is
always room for imporovement. But what I'm doing is not unittest. My
program is controling and instrument (an x-ray powder
diffractometer) and some parts of the instrument are not working for
the moment, so i want to disable all error i get from this instrument
(are coded like exceptions)

Zunbeltz
-Peter

--
Zunbeltz Izaola Azkona | wmbizazz at lg dot ehu
dotes
Materia Kondentsatuaren Fisika Saila |
Zientzia eta Teknologia Fakultatea | Phone: [phone]
Euskal Herriko Unibertsitatea |
PK 644 | Fax: [phone]
48080 Bilbo (SPAIN) |

[Irmen de Jong]

Zunbeltz Izaola wrote:

Possibly the code should be restructered, and re-designed; there is
always room for imporovement. But what I'm doing is not unittest. My
program is controling and instrument (an x-ray powder
diffractometer) and some parts of the instrument are not working for
the moment, so i want to disable all error i get from this instrument
(are coded like exceptions)

What I usually do in comparable situations is to write STUB code for
the parts of the system that don't work yet.
Write your stub code so that it does nothing, but doesn't raise any
exceptions too. The only thing you then have to do is write the rest
of the code as you would have done, and once the Stubbed parts work,
replace the stub code with the real code.

--Irmen

[Calvin Spealman]

Peter Hansen wrote:

Zunbeltz Izaola wrote:

I've trid this, but the problem is that this finished the try block.
I want to continue executing the try block from the point the
exception was raised.

Not possible except, perhaps, with a significant amount of
working involving sys.settrace(). I think you need to find
another way to solve the problem.

Have to admit tho, a continue feature might be useful. Some languages have
this, don't they? The thing is, Where exactly to continue? Should you retry
whatever raised the exception, continue just after it, at the beginning of
that line, or what?

[Scott David Daniels]

Calvin Spealman wrote:

...
Have to admit tho, a continue feature might be useful. Some languages have
this, don't they? The thing is, Where exactly to continue? Should you retry
whatever raised the exception, continue just after it, at the beginning of
that line, or what?

See this older thread:
<http://groups.google.com/groups?threadm=3edd6118%241%40nntp0.pdx.net>

Xerox's experience (in deliberately removing the "continue from
exception" language feature) I found very instructive.

-Scott David Daniels
Sc***********@Acm.Org

[John J. Lee]

Irmen de Jong <[e-mail]> writes:

Zunbeltz Izaola wrote:

Possibly the code should be restructered, and re-designed; there is
always room for imporovement. But what I'm doing is not unittest. My
program is controling and instrument (an x-ray powder
diffractometer) and some parts of the instrument are not working for
the moment, so i want to disable all error i get from this instrument
(are coded like exceptions)

What I usually do in comparable situations is to write STUB code for
the parts of the system that don't work yet.
Write your stub code so that it does nothing, but doesn't raise any
exceptions too. The only thing you then have to do is write the rest
of the code as you would have done, and once the Stubbed parts work,
replace the stub code with the real code.

....and if you think you want to get exceptions later:

def fixme():
pass
Sprinkle fixme()s through your code, then redefine later:

def fixme():
raise NotImplementedError()
John

[Peter Hansen]

Zunbeltz Izaola wrote:

Peter Hansen <pe***@engcorp.com> writes:

Zunbeltz Izaola wrote:

I want to continue executing the try block from the point the
exception was raised.
Not possible except, perhaps, with a significant amount of
working involving sys.settrace(). I think you need to find
another way to solve the problem.

But what I'm doing is not unittest.

Pardon: I don't know why I thought this was related to testing
code.
My program is controling and instrument (an x-ray powder
diffractometer) and some parts of the instrument are not working for
the moment, so i want to disable all error i get from this instrument
(are coded like exceptions)

What is the interface to the instrument? Is there some sort of
driver/wrapper layer that handles the communication with the
device? Your only hope, I think, is to intercept things at
that level and avoid/trap the exceptions before they get up
to the higher level. In effect, stubs as Irmen suggested...

It sounds like you are quite capable of figuring it out at
this point, though, since all you wanted to know was whether
you could continue after an exception and now you know you
cannot. :-)

-Peter

[Ng Pheng Siong]

According to Scott David Daniels <Sc***********@Acm.Org>:

Calvin Spealman wrote:

...
Have to admit tho, a continue feature might be useful. Some languages have
this, don't they? The thing is, Where exactly to continue? Should you retry
whatever raised the exception, continue just after it, at the beginning of
that line, or what?

See this older thread:
<http://groups.google.com/groups?threadm=3edd6118%241%40nntp0.pdx.net>

Xerox's experience (in deliberately removing the "continue from
exception" language feature) I found very instructive.

Are the bugs mainly in the implementation of that feature, or in user
code attempting to use said feature?

(I notice the older thread was one year ago. Is this an annual topic? ;-)

BTW, Common Lisp has this, called "restarts". There are about half a dozen
Common Lisp implementations and none appear to have gotten restarts
terribly wrong.

Cheers.
--
Ng Pheng Siong <ng**@netmemetic.com>

http://firewall.rulemaker.net -+- Firewall Change Management & Version Control
http://sandbox.rulemaker.net/ngps -+- ZServerSSL/Zope Windows Installers

[Jeff Epler]

> According to Scott David Daniels <Sc***********@Acm.Org>:

See this older thread:
<http://groups.google.com/groups?threadm=3edd6118%241%40nntp0.pdx.net>

On Tue, Jun 01, 2004 at 12:59:29AM +0000, Ng Pheng Siong wrote: (I notice the older thread was one year ago. Is this an annual topic? ;-)

Perhaps the older thread had an exception, but now it's been re-started?

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAu/DWJd01MZaTXX0RAjtjAJ9U2x7VZ4Et2LwlH7B4mFK7gXQyEwCe KwlA
l1ze/lr+g0ena9p+Sq87e9I=
=PqxJ
-----END PGP SIGNATURE-----

[Jacek Generowicz]

Scott David Daniels <Sc***********@Acm.Org> writes:

Calvin Spealman wrote:

...
Have to admit tho, a continue feature might be useful. Some languages have
this, don't they? The thing is, Where exactly to continue? Should you retry
whatever raised the exception, continue just after it, at the beginning of
that line, or what?

See this older thread:
<http://groups.google.com/groups?threadm=3edd6118%241%40nntp0.pdx.net>

Xerox's experience (in deliberately removing the "continue from
exception" language feature) I found very instructive.

Funny, Common Lisp (and some of its ancestors) allows you to "fiddle
things and and return as well as even return from the exception", and
people who write industrial strength applications is Common Lisp
repeatedly state that this feature allows them to write software which
is much more robust than any they would otherwise be able to
create. Some go as far as considering any language without this
feature to be fundamentally flawed. I have never heard anyone identify
this feature as a source of bugs.

So I am tempted to conclude that the Mesa implementation was flawed
.... or maybe it was just the users who were flawed. The concept itself
seems to have proven its worth over time.

[Zunbeltz Izaola]

Peter Hansen <pe***@engcorp.com> writes:

Pardon: I don't know why I thought this was related to testing
code.
No problem :-)

My program is controling and instrument (an x-ray powder
diffractometer) and some parts of the instrument are not working for
the moment, so i want to disable all error i get from this instrument
(are coded like exceptions)
What is the interface to the instrument? Is there some sort of
driver/wrapper layer that handles the communication with the
device? Your only hope, I think, is to intercept things at
that level and avoid/trap the exceptions before they get up
to the higher level. In effect, stubs as Irmen suggested...

Finally I do something similar to Irmen's suggestion.
It sounds like you are quite capable of figuring it out at
this point, though, since all you wanted to know was whether
you could continue after an exception and now you know you
cannot. :-)

Yes, I only wanted to know if there was an easy way to continue after
an exception; and I can't (nobody can :-)

Thanks to all for your answers (and sorry for re-starting and annual
thread)

Zunbeltz
-Peter

--
Zunbeltz Izaola Azkona | wmbizazz at lg dot ehu
dotes
Materia Kondentsatuaren Fisika Saila |
Zientzia eta Teknologia Fakultatea | Phone: [phone]
Euskal Herriko Unibertsitatea |
PK 644 | Fax: [phone]
48080 Bilbo (SPAIN) |

[Alexander Schmolck]

Scott David Daniels <Sc***********@Acm.Org> writes:

Calvin Spealman wrote:

...
Have to admit tho, a continue feature might be useful. Some languages have
this, don't they? The thing is, Where exactly to continue? Should you retry
whatever raised the exception, continue just after it, at the beginning of
that line, or what?

See this older thread:
<http://groups.google.com/groups?threadm=3edd6118%241%40nntp0.pdx.net>

Xerox's experience (in deliberately removing the "continue from
exception" language feature) I found very instructive.

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).

'as
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.

[John J. Lee]

Peter Hansen <pe***@engcorp.com> writes:

Zunbeltz Izaola wrote:

[...]

But what I'm doing is not unittest.

Pardon: I don't know why I thought this was related to testing
code.

[...]

It couldn't be that you're obsessed with unit testing, of course
<wink>.
John

[Larry Bates]

I'm going to jump in here and make an observation.
It sounds like you have too much code in a single
try/except block. If you have independent calls
to instrument interface put each of them that might
fail in a separate try/except block. I've needed
to do this in an earlier project and I log errors
in a log file for review.

Something like:

try: data=getsomedatafrominstrumentfunc1()
except:
logf.writelines("W","Unable to communicate with func1")

try: data=getsomedatafrominstrumentfunc2()
except:
logf.writelines("W","Unable to communicate with func2")

My understanding is that try/except overhead is very low
(especially if there is not an exception).

HTH,
Larry Bates
Syscon, Inc.

"Zunbeltz Izaola" <zu******@wm.lc.ehu.es.XXX> wrote in message
news:ct*************@lcpxdf.wm.lc.ehu.es...

Peter Hansen <pe***@engcorp.com> writes:

Pardon: I don't know why I thought this was related to testing
code.

No problem :-)

My program is controling and instrument (an x-ray powder
diffractometer) and some parts of the instrument are not working for
the moment, so i want to disable all error i get from this instrument
(are coded like exceptions)

What is the interface to the instrument? Is there some sort of
driver/wrapper layer that handles the communication with the
device? Your only hope, I think, is to intercept things at
that level and avoid/trap the exceptions before they get up
to the higher level. In effect, stubs as Irmen suggested...

Finally I do something similar to Irmen's suggestion.

It sounds like you are quite capable of figuring it out at
this point, though, since all you wanted to know was whether
you could continue after an exception and now you know you
cannot. :-)

Yes, I only wanted to know if there was an easy way to continue after
an exception; and I can't (nobody can :-)

Thanks to all for your answers (and sorry for re-starting and annual
thread)

Zunbeltz

-Peter

--
Zunbeltz Izaola Azkona | wmbizazz at lg dot ehu
dotes
Materia Kondentsatuaren Fisika Saila |
Zientzia eta Teknologia Fakultatea | Phone: [phone]
Euskal Herriko Unibertsitatea |
PK 644 | Fax: [phone]
48080 Bilbo (SPAIN) |

[Hung Jung Lu]

Alexander Schmolck <a.********@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

[Michael Hudson]

Alexander Schmolck <a.********@gmx.net> writes:

Scott David Daniels <Sc***********@Acm.Org> writes:

Calvin Spealman wrote:

...
Have to admit tho, a continue feature might be useful. Some languages have
this, don't they? The thing is, Where exactly to continue? Should you retry
whatever raised the exception, continue just after it, at the beginning of
that line, or what?
See this older thread:
<http://groups.google.com/groups?threadm=3edd6118%241%40nntp0.pdx.net>

Xerox's experience (in deliberately removing the "continue from
exception" language feature) I found very instructive.

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).

I'd like this too. It might be quite hard to implement
non-disruptively but I haven't thought about it too hard. Would make
an excellent project for a master's thesis, IMHO.
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.

What do you mean here, specifically?

I find I can do interactive development in Python most of the time (I
do wish it was more possible with PyObjC, though).

Cheers,
mwh

--
I think perhaps we should have electoral collages and construct
our representatives entirely of little bits of cloth and papier
mache. -- Owen Dunn, ucam.chat, from his review of the year

[Peter Hansen]

John J. Lee wrote:

Peter Hansen <pe***@engcorp.com> writes:

Zunbeltz Izaola wrote:

[...]

But what I'm doing is not unittest.

Pardon: I don't know why I thought this was related to testing
code.

[...]

It couldn't be that you're obsessed with unit testing, of course
<wink>.

Perhaps that's it. Another viable theory is that I spend
so much time answering questions here that sometimes I fail
to read the requests carefully enough. Doubtless there
are other possibilities.

-Peter

[Alexander Schmolck]

Michael Hudson <mw*@python.net> writes:

Alexander Schmolck <a.********@gmx.net> writes:

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).

I'd like this too. It might be quite hard to implement
non-disruptively but I haven't thought about it too hard. Would make
an excellent project for a master's thesis, IMHO.

Footnotes:
[1] Number 2 would be the stupid try: finally: idiom which also seems to
screw up tracebacks

?

I verified that this doesn't happen with plain python -- ipython's traceback
pretty printing code however doesn't display the right line for frames where
the exception occured within try: finally:. I've now tracked it down to the
use of inspect.getinnerframes, the line numbers here are subtly different from
what traceback.extract_tb returns (last executed expression in frame vs. where
the error occured). Since I couldn't find something readymade, I'll submit
some patch to ipython that merges the functionality of the two functions.

(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.

What do you mean here, specifically?

In no particular order:

- Interactively redefining modules or classes in a way that propogates
to other modules/preexisting instances is not exactly fun. One can often
get by by judicious use of reload, mutating classes [1] (got to be careful
to to avoid pickle failing with something along the lines of
"myModule.myClass is not of type myModule.myClass")

- no images, i.e. you can't freeze and dump the state of the whole system

- it's not particularly easy or convenient to get an useful overview of the
variables in your "workspace", e.g. memory consumption, narrowing down to
"interesting" categories etc (I know that there is of course no general way
of doing that, but compare e.g. for matlab)

- pdb is uhm, well... suboptimal (also crashes on me from time to time, not
sure why)

- global variables in python are a painful in a number of ways that does
affect interactive development

- there is not much of a culture to make modules work properly for interactive
users -- things are often not reload-safe, export all sorts of crap, not
just their interface (so that 'from foo import *' likely will hose things up
-- this is slightly aggravated 'helpful' naming conventions such as
datetime.datetime or StringIO.StringIO). Finally I think some modules,
notably GUI toolkits won't work at all.

- the available IDEs I know of are clearly far from ideal. I'd venture the
uneducated guess that ipython+emacs is amongst the best offerings for
interactive development with python and it's really not that great -- e.g.
if you use the py-execute commands source level debugging no longer will
work since the temp file created by python-mode for execution will be gone
(you can of course hang on to it, which is actually what I wound up doing
but that's very risky -- you end up inadvertenly fixing temp-files rather
than the real thing. I guess it might help if there were some easy way to
exec(file) a string, but lie about were it came from (i.e. ``exec foo,
filename="bla.py", startline=10)). In case anyone wonders that given my
misgivings about pdb I'm bothered about this -- well, one can easily set up
emacs/ipython to jump to right file and line when an error in your
interactive session occurs (and than walk up and down the traceback). This
is **very** useful, I have it activated pretty much all the time.

I find I can do interactive development in Python most of the time (I
do wish it was more possible with PyObjC, though).

I'm not saying it's impossible (I *always* run ipython in emacs, never python
in the commandline on a file, with the sole exception of regression test) but
kludging a workable interactive enviroment together needs, I think, a fair
amount of expertise and additional software (something like ipython+emacs) --
so I'd guess that most people primarily treat python as a really fast C
compiler (but I might be wrong), which is a pitty.

Also, whlilst python interactive offerings might be great when compared to
Java and C++( thankfully I haven't tried), it clearly falls far short of what
is in principle achievable and indeed has been often been achieved many, many
years ago (squeak, cmucl/sbcl+slime, matlab, j and plt scheme, to name just a
few all have things to offer for interactive work that a python user can only
dream of).
'as
Footnotes:

[1] Here are a few of the hacks I'm using, in case anyone might find them
useful -- or even better tell me about better alternatives (If someone has
cooked something reasoable for reloading modules, I'd love to hear about
it).

# to update all existing class instances

def updateClass(oldClass, newClass):
"""Destrucitively modify the ``__dict__`` and ``__bases__`` contents of
`oldClass` to be the same as of `newClass`. This will have the effect that
`oldClass` will exhibit the same behavior as `newClass`.

Won't work for classes with ``__slots__`` (which are an abomination
anyway).
"""
assert type(oldClass) is type(newClass) is type #FIXME
#FIXME redefinition of magic methods
for name in dir(oldClass):
if not name.startswith('__') or not name.endswith('__'):
delattr(oldClass, name)
for name in dir(newClass):
if not name.startswith('__') or not name.endswith('__'):
setattr(oldClass, name, newClass.__dict__[name])
# XXX should check that this is absolutely correct
oldClass.__bases__ = newClass.__bases__
## easy pickling and unpickling for interactive use

def magicGlobals(level=1):
r"""Return the globals of the *caller*'s caller (default), or `level`
callers up."""
return inspect.getouterframes(inspect.currentframe())[1+level][0].f_globals

def __saveVarsHelper(filename, varNamesStr, outOf,extension='.bpickle',**opts):
filename = os.path.expanduser(filename)
if outOf is None: outOf = magicGlobals(2)
if not varNamesStr or not isString(varNamesStr):
raise ValueError, "varNamesStr must be a string!"
varnames = varNamesStr.split()
if not splitext(filename)[1]: filename += extension
if opts.get("overwrite") == 0 and os.path.exists(filename):
raise RuntimeError("File already exists")
return filename, varnames, outOf

def saveVars(filename, varNamesStr, outOf=None, **opts):
r"""Pickle name and value of all those variables in `outOf` (default: all
global variables (as seen from the caller)) that are named in
`varNamesStr` into a file called `filename` (if no extension is given,
'.bpickle' is appended). Overwrites file without asking, unless you
specify `overwrite=0`. Load again with `loadVars`.

Thus, to save the global variables ``bar``, ``foo`` and ``baz`` in the
file 'savedVars' do::

saveVars('savedVars', 'bar foo baz')

"""
filename, varnames, outOf = __saveVarsHelper(
filename, varNamesStr, outOf, **opts)
print "pickling:\n", "\n".join(isort(varnames))
try:
f = None
f = open(filename, "wb")

cPickle.dump(dict(zip(varnames, [outOf, varnames])),
f, 1) # UGH: cPickle, unlike pickle doesn't accept bin=1
finally:
if f: f.close()

def loadVars(filename, ask=True, into=None, only=None):
r"""Load variables pickled with `saveVars`.
Parameters:

- `ask`: If `True` then don't overwrite existing variables without
asking.
- `only`: A list to limit the variables to or `None`.
- `into`: The dictionary the variables should be loaded into (defaults
to global dictionary).
"""
filename = os.path.expanduser(filename)
if into is None: into = magicGlobals()
varH = loadDict(filename)
toUnpickle = only or varH.keys()
alreadyDefined = filter(into.has_key, toUnpickle)
if alreadyDefined and ask:
print "The following vars already exist; overwrite (yes/NO)?\n",\
"\n".join(alreadyDefined)
if raw_input() != "yes":
toUnpickle = without(toUnpickle, alreadyDefined)
if not toUnpickle:
print "nothing to unpickle"
return None
print "unpickling:\n",\
"\n".join(isort(list(toUnpickle)))
for k in varH.keys():
if k not in toUnpickle:
del varH[k]
into.update(varH)

[Hung Jung Lu]

Alexander Schmolck <a.********@gmx.net> wrote:

[1] Here are a few of the hacks I'm using, in case anyone might
find them useful -- or even better tell me about better
alternatives (If someone has cooked something reasoable
for reloading modules, I'd love to hear about it).

I have already answered to you on one previous occasion, and told you
another time in this present thread. I've used this kind of trick in
wxPython. It's good for interactively developing widgets, without
re-starting your program.

Now here is a third try. :)

(
For the first time, see:
http://groups.google.com/groups?q=g:...ing.google.com
)

You can of course use a metaclass to make things a bit easier. Here is
a draft version.

#----- autoupdate.py
'''metaclass for auto-update classes'''
class __metaclass__(type):
# automatically keeps tracks of instances
def __new__(cls, class_name, bases, class_dict):
import inspect
module_name = class_dict['__module__']
instance_dict_name = '_%s__instances' % class_name
# see if there is already an older class
import sys
old_instance_dict = None
if sys.modules.has_key(module_name):
module = sys.modules[module_name]
if hasattr(module, class_name):
old_instance_dict = getattr(
getattr(module, class_name),
instance_dict_name)
# add instance list
import weakref
class_dict[instance_dict_name] = weakref.WeakValueDictionary()
# override the __init__
if class_dict.has_key('__init__'):
def new_init(self, *args, **kw):
instance_dict_name = '_%s__instances' % (
self.__class__.__name__)
getattr(self.__class__,
instance_dict_name)[id(self)] = self
self.__original_init__(*args, **kw)
class_dict['__original_init__'] = class_dict['__init__']
class_dict['__init__'] = new_init
else:
def new_init(self, *args, **kw):
instance_dict_name = '_%s__instances' % (
self.__class__.__name__)
getattr(self.__class__,
instance_dict_name)[id(self)] = self
class_dict['__init__'] = new_init
# build the class, with instance_dict
new_class = type.__new__(cls, class_name, bases, class_dict)
# copy over the instance dictionary, and update __class__
if old_instance_dict is not None:
for instance_id, instance in (
old_instance_dict.iteritems()):
getattr(new_class,
instance_dict_name)[instance_id] = instance
instance.__class__ = new_class
# return new class
return new_class

#----- Spam.py
from autoupdate import __metaclass__
class Egg:
'''Put here your class code'''
# def print(self):
# print 'Hello World!'

#----- from your Python console
import Spam
x = Spam.Egg()
# ... edit your Spam.py file and change code for Spam.Egg class,
# e.g.: add a print() method to Spam.Egg by uncommenting
# the corresponding lines. Save the file.
reload(Spam)
x.print() # prints 'Hello World!'

---------------------

regards,

Hung Jung

[Alexander Schmolck]

hu********@yahoo.com (Hung Jung Lu) writes:

Alexander Schmolck <a.********@gmx.net> wrote:

[1] Here are a few of the hacks I'm using, in case anyone might
find them useful -- or even better tell me about better
alternatives (If someone has cooked something reasoable
for reloading modules, I'd love to hear about it).
I have already answered to you on one previous occasion,

Sorry, maybe I missed it (at the time I had no access to a reliable
newsserver, so many articles didn't show up).
and told you another time in this present thread.
Yep, I've guessed correctly that your mention of weakrefs alluded to a
technique along those lines -- I haven't finished my reply to your article yet
as I sunk quite a bit of time on debugging IPython yesterday.
I've used this kind of trick in wxPython. It's good for interactively
developing widgets, without re-starting your program.

Now here is a third try. :)

Thanks for your trying again, I've only had time for a glance but this looks
quite neat -- I notice that it has evolved a bit since your original posting
:)

So far I have shied away from a metaclass based solution, as I got by with the
simple hack I posted and this hack doesn't require modifications to source
code. Another reason was that metaclasses don't combine well, but since I
haven't ended up using metaclasses much so far that might not be a problem. So
thanks for posting this, it looks quite useful.

'as

[Alexander Schmolck]

hu********@yahoo.com (Hung Jung Lu) writes:

There are a few lessons learnt from younger programming languages,
like Io.
I'm a bit suprised we have to learn from IO given that at least on superficial
inspection, IO mostly seems to self as ruby is to smalltalk.
One lesson is that you really would like to avoid rigid statement syntax.
How do younger languages like IO make this point more forcefully than lisp,
smalltalk etc -- languages which have been around for decades?

I also suspect that the statement/expression distinction is beneficial at
least for inexperienced programmers (a declared target audience of python),
simply because it means that there are less ways to express the same thing and
nesting is limited -- in other words, I believe there is some trade off
involved.
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.
I don't think having try/except functions instead of statements provides a
sufficient solution. Apart from the fact that functions in themselves don't
provide an adequate control flow mechanism for exceptions, I don't want to
have to write my own error handling mechanisms in order to be able to deal
with some limited subset of errors raised in *my* code -- I want to be able to
deal with *all* errors in an interactive session, no matter where they were
raised and I don't want to have to rewrite (or slow down) *any* code in order
to do so.
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.
It would allow some interception, but I don't think enough for my heart's
content because exceptions are completely different beasts from functions,
certainly in python (dynamically scoped ones, for starters).
In comparison, Python's exception handling is not interceptible, because
exception handling is hard-coded in syntax.
I don't think syntax is the sticking point here -- you could do some
additional, possibly useful, things if raise where, say, a method, but I can't
see how it would go anywhere near solving the problem.
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.
Such an approach doesn't really help much -- not only because I obviously
can't (and don't want to) rewrite all the code that might raise an exception
(which often isn't even python).
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.)
Yes, but this is clearly insufficient.
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,
I don't see how prototype-based languages have a particular edge here --
Common lisp and Dylan, for example, support continuable conditions and can
hardly be called protype-based.
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.
I know -- I currently don't depend on weakref, but I use reload quite a lot
and I do all my programming in interactive sessions which sometimes last days.
It does not come as part of the language per-se. You need to build up some
tools yourself first.

This is one of the sticky points -- it requires some work and expertise (and
even then you are a long way off from e.g. smalltalk) and this in turn is
likely to mean that most python users won't get to experience the benefits of
interactive development (which in turn presumably means that libraries and
utilities often don't cater well for interactive use).

'as

[Hung Jung Lu]

Alexander Schmolck <a.********@gmx.net> wrote:

How do younger languages like IO make this point more forcefully than lisp,
smalltalk etc -- languages which have been around for decades?
Sorry, the last time I used Lisp was more than 20 years ago. I might
have to look it up again. I tend to rely on people that have more
experience. Io was based on experience from lots of other languages.
with some limited subset of errors raised in *my* code -- I want to be able to
deal with *all* errors in an interactive session, no matter where they were
raised and I don't want to have to rewrite (or slow down) *any* code in order
to do so.
One typical example mentioned in AOP is precisely exception handling.
If you look at Python's internal way of handling exception (read the
manual part on extending and embedding,) errors are typically
indicated by returning a NULL value. And there are a few functions to
call to set exceptions. That is, internally, Python exceptions are
implemented going through function mechanisms, any how. Now, if these
functions could be interceptible a la AOP, there you go with "catching
*all* errors."

Sure, I understand you don't want to write any code. You just want to
be the end user and enjoy the free ride. But someone has to write it,
at some level. What you are saying is that you don't want to be this
someone. All the nice interactive, edit-and-continue features in the
various languages are not born out of magic, they were written by
someone, right? :)
It would allow some interception, but I don't think enough for my heart's
content because exceptions are completely different beasts from functions,
certainly in python (dynamically scoped ones, for starters).
Exceptions in Python are implemented as (a) returning typically a NULL
value in Python functions at the C level, (b) setting exception
informations in global static variables, often via usage of some
functions like PyErr_SetString(). And in this regard, conceptually is
not different from AOP way of exception handling. And in this regard,
perfectly interceptible via function overrides, if it were not C but
some other language a la Io.

What I am saying is, it is totally possible to design a language where
exceptions are implemented using AOP approach, where each function
could return an additional implicit value (or a NULL value as in the
case of Python.) Now, the function (or "metafunction") in your AOP
code that handles the exception raising or catching can be overridden,
if you are using something like Io where all functions can be
overriden. That is, exception handling conceptually can be done via
functions. And in Microsoft C++, this is in fact the way how
exceptions are implemented: by including an extra return value. It's
just too bad that the end user cannot override internal C/assembler
functions. (There are products to do this type of overriding.
Profilers, memory leak detectors, debuggers, etc. are good examples...
in their "instrumentation" phase, they do AOP-ish insertion of
additional code and override the normal behavior.)

In short, for many language implementations, exceptions ultimately are
based on function features. They are not "completely different
beasts". Mostly everything ultimately comes down to plain-vanilla
function calls.

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.

Such an approach doesn't really help much -- not only because I obviously
can't (and don't want to) rewrite all the code that might raise an exception
(which often isn't even python).

I know, that's why I said "it does not mean all hope is lost". It
doesn't help much, but it helps a little.
Yes, but this is clearly insufficient.
Do you have any better idea? Short of stopping whining and starting to
re-write the Python interpreter yourself? I am sure you are totally
welcome to do so. :)

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,

I don't see how prototype-based languages have a particular edge here --

It does. You just don't see it. Most people can't see it. And I am not
telling the details. :) Smart people know what I am talking about. And
I'll just leave it at that. Sorry, can't say anymore. :)
I know -- I currently don't depend on weakref,
Weakref is the key, at least that was my experience. I urge you to
think again on why weakrefs are necessary. Whether to use metaclass,
AOP-ish approach, or brute force class changes, it's all just icing on
the cake. Weakref was the key, in my experience.
This is one of the sticky points -- it requires some work and expertise (and
even then you are a long way off from e.g. smalltalk) and this in turn is
likely to mean that most python users won't get to experience the benefits of
interactive development (which in turn presumably means that libraries and
utilities often don't cater well for interactive use).

I know. Python has been criticized from many directions. But you
either live with the workarounds, or stop whining and do the work
inside the interpreter so others can enjoy your work. :) In my
personal case, I choose the first alternative. The advantage is that I
can keep whining. I am almost sure that this would also be your
choice. :)

regards,

Hung Jung