[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1156375 - /subversion/branches/fs-py/subversion/python/svn/fs.py

From: Hyrum K Wright <hyrum.wright_at_wandisco.com>
Date: Wed, 10 Aug 2011 19:20:54 -0500

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.


* 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

uberSVN: Apache Subversion Made Easy
Received on 2011-08-11 02:21:25 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.