Scanning a file
pwatson at redlinepy.com
Mon Oct 31 21:05:37 CET 2005
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
>> 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.
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.
More information about the Python-list