On Wed, Aug 10, 2011 at 6:42 PM, Greg Stein <gst...@gmail.com> wrote: > On Wed, Aug 10, 2011 at 17:44, Hyrum K Wright <hyrum.wri...@wandisco.com> > wrote: >>... >>> And now where did your .close() call go? You're still relying on 'f' >>> going out of scope to close. IOW, right back to the zero refcount >>> algorithm. And in which case, the original construction is much >>> cleaner than all this "with" gunk. >> >> In the case of an open()'d file, the file is closed when the object is >> eventually garbage collected, which, by documentation[1] isn't >> guaranteed to happen when the object is unreachable: "Do not depend on >> immediate finalization of objects when they become unreachable (ex: >> always close files)." Hence the need for an explicit close. > > That is referring to circular references, where all objects in the > circle are (no longer) referenced from outside the circle. > > Given: > > open(file).read() > > You get a reference to the file, it is stashed into a bound method > object, the method is invoked with another reference increasing as the > file is bound to 'self'. When the method returns, the bound method is > decref'd which decref's the file, which closes it.
Correct. This is not a circular reference, but rather uses an anonymous object or two. The general point is that relying upon an implementation detail as to the timeliness of the GC is probably not a good idea. Although the docs I cited did refer to circular references, I think the general point about not relying upon implementation details is a valid one. (One of the benefits of a Python implementation is that somebody could run it in CPython or PyPy or IronPython or Jython or Cython or $FOO. I'd rather not make assumptions which limit those options when we don't have to.) >>... >> As for "gunk," the with construction was introduced in Python 2.5, >> almost 5 years ago and I find it cleaner. > > I find the use of control flow construct to replace a simple > expression... to be more complicated. Has no bearing on how long > 'with' has been around. Fair enough. I feel the nature of the with syntax lends itself to better comprehension of what's going on. We can agree to disagree. :) > And now that you mention it... we have always said that our delivered > Python code (as distinct from our build/test environment) should be > compatible with Python 2.4. I don't recall that we've changed that > position. Actually, we don't require users to have *any* version of Python installed to run Subversion. If you install a vanilla Subversion client from your local package manager, it's not going to pull in Python as a run-time dependency. As this (still highly experimental*) work would obviously introduce that dependency, and requiring something as ancient as Python 2.5 isn't further adding to that burden. Oh, and for the record, I didn't interpret Greg's comments as jumping on me, though I see how others could. I've learned to appreciate (and deal with) his rather direct style in reviewing code. -Hyrum * Let's not forget that this is an experimental branch with (in my opinion) a low probability of ever being release as part of the core product. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
