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

Jason Roberts jason.roberts at duke.edu
Fri Sep 17 15:02:58 EDT 2010


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/4506b9a9/attachment.html


More information about the gdal-dev mailing list