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

Re: svn commit: r16211 - trunk/subversion/bindings/swig/python/svn

From: André Malo <nd_at_perlig.de>
Date: 2005-09-23 00:08:47 CEST

* David James wrote:

> > The leaks probably need to be solved by explicitly calling pool.clear()
> > at the proper places (using subpools and try: finally: may be a good
> > choice).
>
> Is this necessary? If you use None as your pool, the SWIG bindings
> should automatically create an anonymous pool for us, which should get
> destroyed automatically at the appropriate time (assuming everything
> works as promised).

The pools are garbage collected - oh well (found the place now...)

But I've got another thing then. Wouldn't it make more sense to make the
pool arguments dummies at all (for backwards compat), i.e. /always/ throw
away any pool from outside and use an anonymous one? The result would be
very pythonic!

For example, this code from svn.fs still uses the supplied pool. I'm
wondering why ;-) Perhaps just an oversight?

  def _dump_contents(self, file, root, path, pool=None):
    fp = __builtin__.open(file, 'w+') # avoid namespace clash with
                                      # trimmed-down svn_fs_open()
    if path is not None:
      stream = file_contents(root, path, pool)
      try:
        while 1:
          chunk = _core.svn_stream_read(stream, _core.SVN_STREAM_CHUNK_SIZE)
          if not chunk:
            break
          fp.write(chunk)
      finally:
        _core.svn_stream_close(stream)
    fp.close()

nd

-- 
"Umfassendes Werk (auch fuer Umsteiger vom Apache 1.3)"
                                          -- aus einer Rezension
<http://pub.perlig.de/books.html#apache2>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 23 00:09:43 2005

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.