Scanning a file

[Paul Watson]

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.