Scanning a file
steve at holdenweb.com
Mon Oct 31 16:07:12 CET 2005
Paul Watson wrote:
> Alex Martelli wrote:
>>[<__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.
> 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.
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/
More information about the Python-list