Marc-Andre Lemburg <m...@egenix.com> added the comment:
Antoine Pitrou wrote:
>
> Antoine Pitrou <pit...@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
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
