Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

Lenard Lindstrom <len-l at telus.net> writes:

>>> Explicitly clear the exception? With sys.exc_clear?

>> Yes.  Is there a problem with that?

> As long as nothing tries to re-raise the exception I doubt it breaks
> anything:
>
>  >>> import sys
>  >>> try:
> 	raise StandardError("Hello")
> except StandardError:
> 	sys.exc_clear()
> 	raise
>
>
> Traceback (most recent call last):
>    File "<pyshell#6>", line 5, in <module>
>      raise
> TypeError: exceptions must be classes, instances, or strings
> (deprecated), not NoneType

I guess I don't really see that as a problem.  Exceptions should
normally only be re-raised where they are caught.  If a piece of code
has decided to handle an exception, and considers it dealt with, there
is no reason for it not to clear the exception, and good reason for it
to do so.  Also, any caught exception is automatically cleared when
the catching procedure returns anyway, so it's not like Python has
ever considered a caught exception to be precious information that
ought to be preserved long past the point where it is handled.

> But it is like calling the garbage collector. You are tuning the
> program to ensure some resource isn't exhausted.

I'm not sure I see the analogy: Calling the GC can be expensive,
clearing an exception is not.  The exception is going to be cleared
anyway when the procedure returns, the GC wouldn't likely be.

It's much more like explicitly assigning None to a variable that
contains a large data structure when you no longer need the contents
of the variable.  Doing this sort of thing can be a wise thing to do
in certain situations.

> It relies on implementation specific behavior to be provably
> reliable*.

As Python is not a formally standardized language, and one typically
relies on the fact that CPython itself is ported to just about every
platform known to Man, I don't find this to be a particular worry.

> If this is indeed the most obvious way to do things in your
> particular use case then Python, and many other languages, is
> missing something. If the particular problem is isolated,
> formalized, and general solution found, then a PEP can be
> submitted. If accepted, this would ensure future and cross-platform
> compatibility.

Well, I think that the refcounting semantics of CPython are useful,
and allow one to often write simpler, easier-to-read and maintain
code.  I think that Jython and IronPython, etc., should adopt these
semantics, but I imagine they might not for performance reasons.  I
don't generally use Python for it's speediness, however, but rather
for it's pleasant syntax and semantics and large, effective library.

|>oug