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

[Douglas Alan]

Duncan Booth <duncan.booth at invalid.invalid> writes:

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

> None of that is relevant.

Of course it is.  I said "large number of tracebacks" up there, and
you promptly ignored that precondition in your subsequent
counterexample.

> Have you ever seen any code looking roughly like this?

> def mainloop():
>    while somecondition:
>       try:
>           dosomestuff()
>       except SomeExceptions:
>           handletheexception()

Of course.

> Now, imagine somewhere deep inside dosomestuff an exception is
> raised while you have a file open and the exception is handled in
> mainloop. If the loop then continues with a fresh call to
> dosomestuff the traceback object will continue to exist until the
> next exception is thrown or until mainloop returns.

It's typically okay in my software for a single (or a few) files to
remain open for longer than I might expect.  What it couldn't handle
is running out of file descriptors, or the like.  (Just like it
couldn't handle running out of memory.)  But that's not going to
happen with your counterexample.

If I were worried about a file or two remaining open too long, I'd
clear the exception in the mainloop above, after handling it.  Python
lets you do that, doesn't it?

|>oug