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. -- http://mail.python.org/mailman/listinfo/python-list
