Scanning a file

[Steve Holden]

Paul Watson wrote:
> 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.

In point oif fact I don't believe the runtime does any such thing 
(though I must admit I haven't checked the source, so you may prove me 
wrong).

As far as I know, Python simply relies on the opreating system to close 
files left open at the end of the program.

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/