Remove Destroy calls from autotest ogr tests?

[Kurt Schwehr]

In looking at ogr_geojson.py, in head, there are lots of calls to .Destroy(). Looking at the doc strings for these, they all say things like this with things like "For backwards compatiblity only" (spelling fixed in r29524):

feature.Destroy?
Type:       instancemethod
String Form:<bound method Feature.Destroy of <osgeo.ogr.Feature; proxy of <Swig Object of type 'OGRFeatureShadow *' at 0x7f919c0c5cf0> >>
File:       /usr/local/lib/python2.7/dist-packages/GDAL-1.11.0-py2.7-linux-x86_64.egg/osgeo/ogr.py
Definition: feature.Destroy(self)
Docstring:  Once called, self has effectively been destroyed.  Do not access. For backwards compatiblity only

Can I remove these from trunk? Will GDAL >= 2.0.0 ever be used with the old API? That would remove 730 Destroy() calls if they can safely go.

grep Destroy autotest/ogr/*.py | wc -l
730

That will also reduce the number of people added unneeded Destroys to their code as autotest is often used as example code.

[Even Rouault]

Kurt, I guess all calls to Feature.Destroy could be safely removed. Concerning calls to DataSource.Destroy, some care should be taken. Some might be completely removed, but others might have to be converted to ds = None, because the file is reopened (or deleted) afterwards and has to been properly closed before.

[Kurt Schwehr]

Thanks for the warning. I'll take it slow with the changes. I started with ogr_geojson.py and went a part at a time. e.g. r29527 and r29529

[Kurt Schwehr]

mingw failure ​https://travis-ci.org/rouault/gdal_coverage/builds/71505938

Script: ogr/ogr_vrt.py
  TEST: ogr_vrt_15 ... fail (blowup)
  TEST: ogr_vrt_16 ... fail (blowup)

I will revert either those two tests or ogr_vrt.py if I can't figure out what is up and it's not a random flake.

[Kurt Schwehr]

r29537 now has ogr_vrt.py failing, but now ogr_mitab.py is failing. That ran fine in the last run.

​https://travis-ci.org/rouault/gdal_coverage/builds/71520111

Script: ogr/ogr_mitab.py
  TEST: ogr_mitab_3 ... fail
    line 92: geometry names do not match
  TEST: ogr_mitab_4 ... fail (blowup)
  TEST: ogr_mitab_5 ... fail
    line 42: did not find required field eas_id
  TEST: ogr_mitab_6 ... fail (blowup)
  TEST: ogr_mitab_9 ... fail
    line 92: geometry names do not match

fixme:msvcrt:MSVCRT__sopen_s : pmode 0x81b6 ignored
Running tests from ogr/ogr_mitab.py
  TEST: ogr_mitab_1 ... success
  TEST: ogr_mitab_2 ... success
  TEST: ogr_mitab_3 ... ERROR 1: "eas_id" not recognised as an available field.
fail
    line 92: geometry names do not match
  TEST: ogr_mitab_4 ... ERROR 1: SELECT from table tpoly failed, no such table/featureclass.
fail (blowup)
Traceback (most recent call last):
  File "pymod\gdaltest_python2.py", line 42, in run_func
    result = func()
  File ".\ogr_mitab.py", line 162, in ogr_mitab_4
    tr = ogrtest.check_features_against_list( sql_lyr, 'prfedea', [ '35043413' ] )
  File "../pymod\ogrtest.py", line 40, in check_features_against_list
    field_index = layer.GetLayerDefn().GetFieldIndex( field_name )
AttributeError: 'NoneType' object has no attribute 'GetLayerDefn'
  TEST: ogr_mitab_5 ... fail
    line 42: did not find required field eas_id
  TEST: ogr_mitab_6 ... fail (blowup)
Traceback (most recent call last):
  File "pymod\gdaltest_python2.py", line 42, in run_func
    result = func()
  File ".\ogr_mitab.py", line 208, in ogr_mitab_6
    datum_name = srs.GetAttrValue('PROJCS|GEOGCS|DATUM')
AttributeError: 'NoneType' object has no attribute 'GetAttrValue'
  TEST: ogr_mitab_7 ... success

[Even Rouault]

I've seen regular failures on ogr_mitab too recently on mingw / mingw-w64 targets. Lately in ​https://s3.amazonaws.com/archive.travis-ci.org/jobs/74076095/log.txt. When trying to run in isolated mode, I can't reproduce.

[Even Rouault]

Looks like it can be closed