Python bindings: allow chaining method calls while preserving C++ objects alive

[Even Rouault]

Currently, a line like ogr.Open('data/poly.shp').GetLayer(0).GetNextFeature().GetGeometryRef().ExportToWkt() causes a crash

[Even Rouault]

I've found a solution for the above issue, but unfortunately it breaks existing code (many tests in autotest suite).

For example :

ds = gdal.Open('foo.tif')
msk = ds.GetRasterBand(1).GetMaskBand()
ds = None
gdal.GetDriverByName('GTiff').Delete('foo.tif')

With the proposed patch, after ds = None, the C++ object is still alive (until msk goes out of scope), so the Delete() can fail on Windows for example because the underlying file handle isn't yet closed...

[hobu]

As I was saying on IRC, the problem that happens is when people were improperly destroying stuff.

I think the above behavior that the autotests has is wrong and broken and should be fixed, but I realize it is a lot of work to do so.

To make this even more ridiculous, what if we made a gdal.ManageObjects() and gdal.DontManageObjects() global method set, similar to the gdal.UseExceptions() stuff we have to allow people to turn this behavior off. I would propose that the new, correct behavior be on by default for GDAL 1.8+, however, with a note in the release notes.

[Jukka Rahkonen]

Is the new, correct behavior now implemented and on by default?

[BrenBarn]

Sorry, but this is completely crazy. The excuse that you can't make GetLayer(0).NextFeature() work because it will break code that explicitly sets something to None and then tries to delete it is feeble at best. The idea that it's "difficult to correct" is even feebler. It's like telling someone their car might explode when they turn the ignition key, but you can't fix it because it would disappoint people who like pouring strawberry jam into their radiator.

Calling methods on objects is basic behavior and should work. Messing around with setting things to None and then trying to pull the rug out from under those objects is not something that needs to be supported. It's not even that method chaining doesn't work; it actually crashes the entire interpreter.

I am curious what other issues could possibly be considered more important than this.

[Jukka Rahkonen]

"I am curious what other issues could possibly be considered more important than this."

Not trying to say that this issue is not important but it has never bothered me. However, I am just an end user, not programmer. Still, last comment on issue being from 5 years ago I believe that I am not alone.

I am curious to know if you can't find any more important issues from this list ​https://trac.osgeo.org/gdal/report/1.

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.