This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients alex, amaury.forgeotdarc, benjamin.peterson, brett.cannon, brian.curtin, exarkun, giampaolo.rodola, lemburg, pitrou
Date 2010-10-29.11:18:33
SpamBayes Score 1.4554469e-12
Marked as misclassified No
Message-id <4CCAAD88.8090705@egenix.com>
In-reply-to <1288340552.3565.17.camel@localhost.localdomain>
Content
Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
>> That's what I'm referring to: most Python applications are
>> written with the fact in mind, that garbage collection will
>> close the files or socket.
>>
>> That's a perfectly fine way of writing Python applications,
> 
> Some people would disagree, especially Windows users who cannot timely
> delete files when some file descriptors still point to them.

There is no difference here:

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.

The only difference is with Python implementations that don't
use synchronous garbage collection, e.g. Jython, but not with
CPython.

>> so why should the programmer get warned about this regular
>> approach to Python programming ?
> 
> Again: it is an *optional* warning. It is *disabled* by default, except
> when compiled --with-pydebug.

Yes, I know. I still find the warning rather useless, since it
warns about code that's perfectly ok.

>> The same applies for sockets.
> 
> It is *definitely* a mistake if the socket has been bound to a local
> address and/or connected to a remote endpoint.

I don't follow you. Where's the difference between writing:

s.close()
or
s = None

for an open socket s ?

>> Think of the simple idiom:
>>
>> data = open(filename).read()
>>
>> This would always create a warning under the proposal.
> 
> We have had many Windows buildbot failures because of such coding style.

Again: where's the difference between writing:

data = open(filename).read()
and
f = open(filename)
data = f.read()
f.close()

?

If the above coding style causes problems, the reasons must be
elsewhere, since there is no difference between those two
styles (other than cluttering up your locals).

The for-loop file iterator support was explicitly added to make
writing:

for line in open(filename):
    print line

possible.

>> If you want to monitor resource usage in your application it
>> would be a lot more useful to provide access to the number of
>> currently open FDs
> 
> Agreed it would be useful as well, but please tell that to operating
> system vendors. Python has no way to calculate such a statistic.

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
History
Date User Action Args
2010-10-29 11:18:36lemburgsetrecipients: + lemburg, brett.cannon, exarkun, amaury.forgeotdarc, pitrou, giampaolo.rodola, benjamin.peterson, alex, brian.curtin
2010-10-29 11:18:34lemburglinkissue10093 messages
2010-10-29 11:18:33lemburgcreate