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

[Douglas Alan]

Jean-Paul Calderone <exarkun at divmod.com> writes:

>>On the other hand, in Python, you can be 100% sure that your files
>>will be closed in a timely manner without explicitly closing them, as
>>long as you are safe in making certain assumptions about how your code
>>will be used.  Such assumptions are called "preconditions", which are
>>an understood notion in software engineering and by me when I write
>>software.

> You realize that Python has exceptions, right?

Yes, of course.

> Have you ever encountered a traceback object?

Yes, of course.

> Is one of your preconditions that no one will ever handle an
> exception raised by your code or by their own code when it is
> invoked by yours?

A precondition of much of my Python code is that callers won't
squirrel away large numbers of tracebacks for long periods of time.  I
can live with that.  Another precondition of much of my code is that
the caller doesn't assume that it is thread-safe.  Another
precondition is that the caller doesn't assume that it is likely to
meet real-time constraints.  Another precondition is that the caller
doesn't need my functions to promise not to generate any garbage that
might call the GC to invoked.

If I had to write all my code to work well without making *any*
assumptions about what the needs of the caller might be, then my code
would have to be much more complicated, and then I'd spend more effort
making my code handle situations that it won't face for my purposes.
Consequently, I'd have less time to make my software have the
functionality that I actually require.

Regarding, specifically, tracebacks holding onto references to open
files -- have you considered that you may actually *want* to see the
file in the state that it was in when the exception was raised for the
purposes of debugging, rather than having it forcefully closed on you?

|>oug