Scanning a file

[Steve Holden]

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/