<div> </div>
<div>Where is Guido ? would be great to hear  his opinion on GIL/ GC issues in future versions of Python.</div>
<div> </div>
<div>regards,</div>
<div>KM</div>
<div><br>----------------------------------------------------------------------------<br> </div>
<div><span class="gmail_quote">On 7 Sep 2006 08:02:57 GMT, <b class="gmail_sendername">Antoon Pardon</b> <<a href="mailto:apardon@forel.vub.ac.be">apardon@forel.vub.ac.be</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On 2006-09-06, <a href="mailto:sjdevnull@yahoo.com">sjdevnull@yahoo.com</a> <<a href="mailto:sjdevnull@yahoo.com">
sjdevnull@yahoo.com</a>> wrote:<br>> Paul Rubin wrote:<br>>> "<a href="mailto:sjdevnull@yahoo.com">sjdevnull@yahoo.com</a>" <<a href="mailto:sjdevnull@yahoo.com">sjdevnull@yahoo.com</a>> writes:
<br>>> > (1) I think is here to stay, if you're going to tell programmers that<br>>> > their destructors can't make program-visible changes (e.g. closing the<br>>> > database connection when a dbconn is destroyed), that's a _huge_ change
<br>>> > from current practice that needs serious debate.<br>>><br>>> We had that debate already (PEP 343).  Yes, there is some sloppy<br>>> current practice by CPython users that relies on the GC to close the
<br>>> db conn.<br>><br>> This point is unrelated to with or ref-counting.  Even the standard<br>> library will close file objects when they are GC'd.<br><br>This is not totally true. My experience is that if you use the
<br>tarfile module any tarfile that was opened for appending or<br>writing risks being corrupted if it isn't closed explicedly.<br><br>--<br>Antoon Pardon<br>--<br><a href="http://mail.python.org/mailman/listinfo/python-list">
http://mail.python.org/mailman/listinfo/python-list</a><br></blockquote></div><br>