[issue10093] Warn when files are not explicitly closed

R. David Murray added the comment: MAL wrote: > Antoine wrote: >> MAL wrote: >>> 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

[issue10093] Warn when files are not explicitly closed

Benjamin Peterson added the comment: 2010/10/29 Marc-Andre Lemburg : > > Marc-Andre Lemburg added the comment: > > Antoine Pitrou wrote: >> >> Antoine Pitrou added the comment: >> >>> The warning will trigger without any reason. >> >> Well, by now you should have understood the reason, so I co

[issue10093] Warn when files are not explicitly closed

Antoine Pitrou added the comment: The buildbots showed no major issue, so this issue is now resolved. The warnings expose a lot of issues in the stdlib that deserve addressing, though ;) -- status: open -> closed ___ Python tracker

[issue10093] Warn when files are not explicitly closed

Marc-Andre Lemburg added the comment: Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >> The warning will trigger without any reason. > > Well, by now you should have understood the reason, so I conclude that > you are either 1) deaf 2) stupid 3) deliberately obnoxious. > > Th

[issue10093] Warn when files are not explicitly closed

Antoine Pitrou added the comment: > The warning will trigger without any reason. Well, by now you should have understood the reason, so I conclude that you are either 1) deaf 2) stupid 3) deliberately obnoxious. This is my last answer to you on this topic. Goodbye. -- ___

[issue10093] Warn when files are not explicitly closed

Marc-Andre Lemburg added the comment: Reposted via the web interface: >> 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 > s

[issue10093] Warn when files are not explicitly closed

Marc-Andre Lemburg added the comment: Antoine Pitrou wrote: > > Antoine Pitrou 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,

[issue10093] Warn when files are not explicitly closed

Antoine Pitrou 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).

[issue10093] Warn when files are not explicitly closed

Marc-Andre Lemburg added the comment: Antoine Pitrou wrote: > > Antoine Pitrou 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 w

[issue10093] Warn when files are not explicitly closed

Antoine Pitrou added the comment: I've committed the patch in r85920; let's watch the buildbots. Also, you'll see many warnings in the test suite if compiled --with-pydebug. -- resolution: -> fixed stage: -> committed/rejected ___ Python tracker

[issue10093] Warn when files are not explicitly closed

Antoine Pitrou added the comment: Here is an updated patch (also fixes a small refleak). -- Added file: http://bugs.python.org/file19411/deallocwarn4.patch ___ Python tracker __

[issue10093] Warn when files are not explicitly closed

Antoine Pitrou 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 Windo

[issue10093] Warn when files are not explicitly closed

Marc-Andre Lemburg added the comment: Brett Cannon wrote: > > Brett Cannon added the comment: > > But this is meant to be an optional warning; users will never see it. Me as a > developer, I would like to know when I leave a file open as that is a waste > of resources, plus with no guarante

[issue10093] Warn when files are not explicitly closed

Brett Cannon added the comment: That's what I thought. So if socket.socket() alone is enough to consume an fd then there should be a warning. -- ___ Python tracker ___

[issue10093] Warn when files are not explicitly closed

Antoine Pitrou added the comment: > If a new, unbound socket uses some form of OS resource, then a warning > is needed. Is their an equivalent limitation like there is with file > descriptors as to how many an OS can possibly have open at once? A socket *is* a file descriptor (under Unix), so,

[issue10093] Warn when files are not explicitly closed

Brett Cannon added the comment: If a new, unbound socket uses some form of OS resource, then a warning is needed. Is their an equivalent limitation like there is with file descriptors as to how many an OS can possibly have open at once? -- ___ Pyth

[issue10093] Warn when files are not explicitly closed

Antoine Pitrou added the comment: I would need opinions on one more thing. The current patch warns when a socket has not been explicitly closed. But it does so even when the socket isn't bound at all. e.g.: $ ./python -c "import socket; socket.socket()" -c:1: ResourceWarning: unclosed Perha

[issue10093] Warn when files are not explicitly closed

Brett Cannon added the comment: But this is meant to be an optional warning; users will never see it. Me as a developer, I would like to know when I leave a file open as that is a waste of resources, plus with no guarantee of everything being flushed to disk. Besides, the context manager for

[issue10093] Warn when files are not explicitly closed

Marc-Andre Lemburg added the comment: I wonder why you think a warning is needed if files aren't closed explicitly. The fact that they get closed on garbage collection is one of the nice features of Python and has made programming easy for years. Explicitly having to close files may have som

[issue10093] Warn when files are not explicitly closed

Brett Cannon added the comment: On Fri, Oct 22, 2010 at 12:49, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > >> After thinking about what warning to go with, I take back my python-dev >> suggestion of ResourceWarning and switch to DebugWarning. > > So what is your advice now? >

[issue10093] Warn when files are not explicitly closed

Antoine Pitrou added the comment: > After thinking about what warning to go with, I take back my python-dev > suggestion of ResourceWarning and switch to DebugWarning. So what is your advice now? I've thought about the DebugWarning name myself and I think it's a rather bad name, because many

[issue10093] Warn when files are not explicitly closed

Brett Cannon added the comment: After thinking about what warning to go with, I take back my python-dev suggestion of ResourceWarning and switch to DebugWarning. It is in fact harder to add in DebugWarning as a superclass to ResourceWarning than the other way around, especially once people st

[issue10093] Warn when files are not explicitly closed

Antoine Pitrou added the comment: > Please add a similar warning in PC/_subprocess.c::sp_handle_dealloc() > I just got caught by this in PyPy because some pipe handle relies on > reference counting to be closed. Do you want to provide a patch? -- _

[issue10093] Warn when files are not explicitly closed

Amaury Forgeot d'Arc added the comment: Please add a similar warning in PC/_subprocess.c::sp_handle_dealloc() I just got caught by this in PyPy because some pipe handle relies on reference counting to be closed. This ad-hoc fix would suppress the warning: http://codespeak.net/pipermail/pypy

[issue10093] Warn when files are not explicitly closed

Antoine Pitrou added the comment: I committed the test fixes to py3k, so here is an updated patch. -- Added file: http://bugs.python.org/file19238/deallocwarn3.patch ___ Python tracker

[issue10093] Warn when files are not explicitly closed

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file19236/deallocwarn3.patch ___ Python tracker ___ ___ Python-bugs-list mail

[issue10093] Warn when files are not explicitly closed

Antoine Pitrou added the comment: Here is a patch adding ResourceWarning, adding new tests, and fixing failures in existing tests. Feedback welcome. -- Added file: http://bugs.python.org/file19236/deallocwarn3.patch ___ Python tracker

[issue10093] Warn when files are not explicitly closed

Antoine Pitrou added the comment: Here is an updated patch using warnings (RuntimeWarning for now) and also warning about unclosed sockets. -- Added file: http://bugs.python.org/file19231/deallocwarn2.patch ___ Python tracker

[issue10093] Warn when files are not explicitly closed

Antoine Pitrou added the comment: > Does this work also for sockets? Not with the current implementation. I guess this could be added, but then I would have to make the warning method ("_dealloc_warn") public on IO classes. -- ___ Python tracker <

[issue10093] Warn when files are not explicitly closed

Giampaolo Rodola' added the comment: Does this work also for sockets? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue10093] Warn when files are not explicitly closed

Changes by Giampaolo Rodola' : -- nosy: +giampaolo.rodola ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:

[issue10093] Warn when files are not explicitly closed

Antoine Pitrou added the comment: There is a slight issue with warnings, and that's the filtering by module/location. Since these warnings will occur in destructors, they can appear at any point without being related to the code being executed. The "default" filtering method (print the first

[issue10093] Warn when files are not explicitly closed

Benjamin Peterson added the comment: 2010/10/13 Alex : > > Alex added the comment: > > RuntimeWarning you mean?  I don't think anyone is suggesting making it an > error. Indeed. -- ___ Python tracker __

[issue10093] Warn when files are not explicitly closed

Alex added the comment: RuntimeWarning you mean? I don't think anyone is suggesting making it an error. -- nosy: +alex ___ Python tracker ___ __

[issue10093] Warn when files are not explicitly closed

Benjamin Peterson added the comment: +1 for RuntimeError. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue10093] Warn when files are not explicitly closed

Changes by Brian Curtin : -- nosy: +brian.curtin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue10093] Warn when files are not explicitly closed

Antoine Pitrou added the comment: > If the warnings are emitted as usual with the warnings module, you can > use -W to control this. Right. Perhaps we can add a new warning category (e.g. ResourceWarning), or simply reuse RuntimeWarning. -- ___ Py

[issue10093] Warn when files are not explicitly closed

Jean-Paul Calderone added the comment: If the warnings are emitted as usual with the warnings module, you can use -W to control this. -X isn't necessary. -- nosy: +exarkun ___ Python tracker

[issue10093] Warn when files are not explicitly closed

Changes by Antoine Pitrou : Added file: http://bugs.python.org/file19225/deallocwarn.patch ___ Python tracker ___ ___ Python-bugs-list mailing

[issue10093] Warn when files are not explicitly closed

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file19224/deallocwarn.patch ___ Python tracker ___ ___ Python-bugs-list maili

[issue10093] Warn when files are not explicitly closed

Antoine Pitrou added the comment: By the way, python-dev discussion was here: http://mail.python.org/pipermail/python-dev/2010-September/104247.html The rough consensus seems to be that there should be a command-line option to enable it, but to enable it by default with pydebug. -- no

[issue10093] Warn when files are not explicitly closed

New submission from Antoine Pitrou : This patch outputs a warning on file deallocation when it hasn't been explicitly closed by the programmer. Printing the warning by default is probably not desirable, but using the patch for "-X" options in issue10089 would allow to switch on when necessary.