[gdal-dev] With Python bindings, should geometry objects created by ogr.Geometry() be explicitly destroyed?

[Jason Roberts]

(Just a side note: Another way that the GDAL Python bindings differ from
typical Python libraries is the need to call gdal.UseExceptions() to have
exceptions be raised when errors occur, and the need to explicitly call
gdal.ErrorReset() in the exception handler, or the same error will keep
occurring on subsequent GDAL API calls.)

 

Now back to the "to destroy or not to destroy" question.

 

From: gdal-dev-bounces at lists.osgeo.org
[mailto:gdal-dev-bounces at lists.osgeo.org] On Behalf Of Jason Roberts
Sent: Friday, September 17, 2010 3:03 PM
To: gdal-dev at lists.osgeo.org
Subject: [gdal-dev] With Python bindings, should geometry objects created by
ogr.Geometry() be explicitly destroyed?

 

I have some Python code that uses OGR geometry objects internally, creating
them like this:

 

point = ogr.Geometry(ogr.wkbPoint)

 

Does this code need to explicitly destroy these geometries, like the
following, to avoid leaks, or can it simply allow them to go out of scope
and have Python's reference counting and garbage collector clean them up?

 

point.Destroy()

 

Does the situation change if I call feature.SetGeometry(point)? What about
feature.SetGeometryDirectly(point)?

 

I'm sorry for my ignorance here. I found a nice GDAL tutorial that seems to
say they *should* be explicitly destroyed in certain circumstances (see
http://www.gis.usu.edu/~chrisg/python/2009/lectures/ospy_slides2.pdf, page
12). But I have not really seen any other examples of this.

 

If you follow gdal-dev, you probably notice that the "to destroy or not to
destroy" question comes up periodically from Python programmers, as does the
problem where someone gets a GDALDataset, gets a band, allows the
GDALDataset to go out of scope, and then expects the band to still work.
These are areas where the GDAL Python bindings to not work like other Python
libraries, causing confusion among Python programmers, who generally expect
reference counting that "just works" and that they only need to explicitly
close something when some kind of I/O is involved.

 

It would be really great if there was FAQ that pointed out all of the ways
that GDAL differs from typical Python libraries. The scenarios I mention
above seem to be two of the most common ones. Would someone be willing to
create it? I would but do not feel competent enough at this point.

 

Thanks,

Jason

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100917/94ecd702/attachment.html