«

On Fri, 29 Jun 2007 09:56:14 -0400, Douglas Alan <> wrote:
>"Chris Mellon" <> writes:
>
>> You're arguing against explicit resource management with the argument
>> that you don't need to manage resources. Can you not see how
>> ridiculously circular this is?
>
>No. It is insane to leave files unclosed in Java (unless you know for
>sure that your program is not going to be opening many files) because
>you don't even know that the garbage collector will ever even run, and
>you could easily run out of file descriptors, and hog system
>resources.
>
>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? Have you ever encountered
a traceback object? 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?

Jean-Paul

Jean-Paul Calderone <> 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

Douglas Alan <> wrote:

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

None of that is relevant.

Have you ever seen any code looking roughly like this?

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

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.

There is no 'squirrelling away' needed here. The point is that it is easy
to write code which accidentally holds onto tracebacks. It is not
reasonable to expect the caller to analyse all situations where the
traceback object could continue to exist.

Duncan Booth <> 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