Paul Watson wrote: > Steve Holden wrote: > >>>Since everyone needs this, how about building it in such that files >>>which are closed by the runtime, and not user code, are reported or >>>queryable? Perhaps a command line switch to either invoke or suppress >>>reporting them on exit. >>> >> >>This is a rather poor substitute from correct program design and >>implementation. It also begs the question of exactly what constitutes a >>"file". What about a network socket that the user has run makefile() on? >>What about a pipe to another process? This suggestion is rather >>ill-defined. >> >> >>>Is there any facility for another program to peer into the state of a >>>Python program? Would this be a security problem? >> >>It would indeed be a security problem, and there are enough of those >>already without adding more. >> >>regards >> Steve > > > All I am looking for is the runtime to tell me when it is doing things > that are outside the language specification and that the developer > should have coded. > > How "ill" will things be when large bodies of code cannot run > successfully on a future version of Python or a non-CPython > implementation which does not close files. Might as well put file > closing on exit into the specification. > > The runtime knows it is doing it. Please allow the runtime to tell me > what it knows it is doing. Thanks.
In point oif fact I don't believe the runtime does any such thing (though I must admit I haven't checked the source, so you may prove me wrong). As far as I know, Python simply relies on the opreating system to close files left open at the end of the program. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list