Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
>> Whether you write an application with automatic closing of
>> the file/socket at garbage collection time in mind, or you explicitly
>> close the file/socket, the timing is the same.
> 
> No, because objects can be kept alive through tracebacks (or reference
> cycles).

If you get a traceback, the explicitly file.close() won't help
you either; but that usually doesn't matter, since program
execution will stop, the traceback will get GCed and the file
closed. This is a very normal and reasonable expectation of a
Python programmer.

>> I don't follow you. Where's the difference between writing:
>>
>> s.close()
>> or
>> s = None
>>
>> for an open socket s ?
> 
> The difference is when s is still referenced elsewhere.
> Also, the intent of the former is clear while the latter is deliberately
> obscure (while not saving any significant amount of typing).

Sure, but that's not the point. It is not a mistake to write
such code and neither is this obscure, otherwise we'd also
require explicit garbage collection for other parts of Python.

If the application keeps references to the objects in other
places, the programmer would, of course, add an explicit .close().
Ditto for the files.

>> The for-loop file iterator support was explicitly added to make
>> writing:
>>
>> for line in open(filename):
>>     print line
>>
>> possible.
> 
> So what?

The warning will trigger without any reason.

>> At least for Linux, that's not hard and I doubt it is for other OSes.
>>
>> 4
>>
>> On other Unixes, you can simply use fcntl() to scan all possible FDs
>> for open FDs.
>>
>> On Windows you can use one of these functions for the same effect:
>> http://msdn.microsoft.com/en-us/library/kdfaxaay(v=VS.90).aspx
> 
> Until you post some code I won't understand what you are talking about.

RoundUp's email interface ate the code. I'll post it again via the
web interface.