Python's "only one way to do it" philosophy isn't good?
Lenard Lindstrom
len-l at telus.net
Mon Jul 2 20:09:21 EDT 2007
Douglas Alan wrote:
> Lenard Lindstrom <len-l at telus.net> 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__.open = __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 telus.net>
More information about the Python-list
mailing list