Python vs Java garbage collection?

[Bengt Richter]

On Sun, 22 Dec 2002 08:43:28 -0500, "John Roth" <johnroth at ameritech.net> wrote:

>
>"Stuart D. Gathman" <stuart at bmsi.com> wrote in message
>news:8L9N9.36408$pe.1368224 at news2.east.cox.net...
>> On Sat, 21 Dec 2002 16:19:19 -0500, Robert Oschler wrote:
>
>> The problem with Python reference counting, is that it encourages
>sloppy
>> programming like:
>>
>>   data = open('myfile','r').read()
>>
>> depending on the reference counting GC to release and close the file
>> object immediately when read() returns.  This habit must be broken
>before
>> Python can evolve to Lisp like speed.  The proper code:
>>
>>   fp = open('myfile','r')
>>   data = fp.read()
>>   fp.close()
>>
>> is not as pretty.  Perhaps some clever pythonista will invent some
>> syntactic sugar to help the medicine go down.
>
>I'm not certain I'd call this sloppy programming. It's a language
>design choice. What you seem to be saying is that the garbage
>collector shouldn't be required to call cleanup methods when it
>releases garbage objects.
>
>The trouble is, that subverts the entire rationalle behind
>garbage collection. If the programmer has to determine when
>an object becomes garbage so it can be finalized properly, then we
>might as well just go back to malloc and free.
>
How about a file read opening mode that means auto-close-when-you-hit-eof?
Since code that seeks back from EOF would break, it can't be default,
but it would allow new code to do e.g., file(name,'R').read() with
assured immediate close (assuming upper case R meant that).
(Or maybe use 'rc'). That would give independence from gc issues.

Regards,
Bengt Richter