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

[Lenard Lindstrom]

Douglas Alan wrote:
> 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.

It is only a problem if refactoring the code could mean the exception is 
re-raised instead of handled at that point. Should the call to exc_clear 
be overlooked then the newly added raise will not work.

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

That's the point. Python takes care of clearing the traceback. Calls to 
exc_clear are rarely seen. If they are simply a performance tweak then 
it's not an issue *. I was just concerned that the calls were necessary 
to keep resources from being exhausted.

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

The intent of a high level language is to free the programmer from such 
concerns as memory management. So a call to the GC is out-of-place in a 
production program. Anyone encountering such a call would wonder what is 
so critical about that particular point in the execution. So 
encountering an exc_clear would make me wonder why it is so important to 
free that traceback. I would hope the comments would explain it.

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

I just delete the name myself. But this is different. Removing a name 
from the namespace, or setting it to None, prevents an accidental access 
later. A caught traceback is invisible.

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

But some things will make it into ISO Python. Registered exit handlers 
will be called at program termination. A context manager's __exit__ 
method will be called when leaving a with statement. But garbage 
collection will be "implementation-defined" **.

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

Just as long as you have weighed the benefits against a future move to a 
JIT-accelerated, continuation supporting PyPy interpreter that might not 
use reference counting.

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

Yet improved performance appeared to be a priority in Python 2.4 
development, and Python's speed continues to be a concern.


* I see in section 26.1 of the Python 2.5 /Python Library Reference/ as 
regards exc_clear: "This function can also be used to try to free 
resources and trigger object finalization, though no guarantee is made 
as to what objects will be freed, if any." So using exc_clear is not so 
much frowned upon as questioned.

** A term that crops up a lot in the C standard /ISO/IEC 9899:1999 (E)/. :-)

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