On Wed, Aug 10, 2011 at 6:42 PM, Greg Stein <gstein_at_gmail.com> wrote:
> On Wed, Aug 10, 2011 at 17:44, Hyrum K Wright <hyrum.wright_at_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/
Received on 2011-08-11 02:21:25 CEST