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

Lenard Lindstrom len-l at
Tue Jul 3 02:09:21 CEST 2007

Douglas Alan wrote:
> Lenard Lindstrom <len-l at> writes:
>>> You don't necessarily want a function that raises an exception to
>>> deallocate all of its resources before raising the exception, since
>>> you may want access to these resources for debugging, or what have
>>> you.
>> No problem:
>> [...]
>>  >>> class MyFile(file):
>> 	def __exit__(self, exc_type, exc_val, exc_tb):
>> 		if exc_type is not None:
>> 			self.my_last_posn = self.tell()
>> 		return file.__exit__(self, exc_type, exc_val, exc_tb)
> I'm not sure I understand you here.  You're saying that I should have
> the foresight to wrap all my file opens is a special class to
> facilitate debugging?
> If so, (1) I don't have that much foresight and don't want to have
> to.  (2) I debug code that other people have written, and they often
> have less foresight than me.  (3) It would make my code less clear to
> ever file open wrapped in some special class.

Obviously you had the foresight to realize with statements could 
compromise debugging. I never considered it myself. I don't know the 
specifics of your particular project, what the requirements are. So I 
can't claim this is the right solution for you. But the option is available.

> Or are you suggesting that early in __main__.main(), when I wish to
> debug something, I do something like:
> = __builtins__.file = MyFile
> ?
> I suppose that would work.

No, I would never suggest replacing a builtin like that. Even replacing 
a definite hook like __import__ is risky, should more than one package 
try and do it in a program.

> I'd still prefer to clear exceptions,
> though, in those few cases in which a function has caught an exception
> and isn't going to be returning soon and have the resources generally
> kept alive in the traceback.  To me, that's the more elegant and
> general solution.

As long as the code isn't dependent on explicitly cleared exceptions. 
But if it is I assume it is well documented.

Lenard Lindstrom
<len-l at>

More information about the Python-list mailing list