Paul Watson wrote: > Alex Martelli wrote: > ... > >>>>>gc.garbage >> >>[<__main__.a object at 0x64cf0>, <__main__.b object at 0x58510>] >> >>So, no big deal -- run a gc.collect() and parse through gc.garbage for >>any instances of your "wrapper of file" class, and you'll find ones that >>were forgotten as part of a cyclic garbage loop and you can check >>whether they were explicitly closed or not. >> >> >>Alex > > > 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 -- 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