<div dir="auto">I think that this is a good change. However, I recommend making this change associated with the GDAL 4.0 release as it is likely going to break existing codebases.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 20, 2023, 12:58 PM Howard Butler <<a href="mailto:howard@hobu.co">howard@hobu.co</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Mar 19, 2023, at 7:34 AM, Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank" rel="noreferrer">even.rouault@spatialys.com</a>> wrote:<br>
> <br>
> Hi,<br>
> <br>
> I've prepared a pull request that does the above, but this raises a number of questions. See my longish comment at <a href="https://github.com/OSGeo/gdal/pull/7475#issuecomment-1475239852" rel="noreferrer noreferrer" target="_blank">https://github.com/OSGeo/gdal/pull/7475#issuecomment-1475239852</a>. Thoughts appreciated<br>
<br>
First off, thank you for doing this. <br>
<br>
Speaking for myself, pretty much all of the <a href="http://ogr.py/gdal.py" rel="noreferrer noreferrer" target="_blank">ogr.py/gdal.py</a> code I've written for the past 15 years has gdal.UseExceptions() after the "from osgeo import gdal" import. The reasons why we had to have this 15 years ago were reasonable, but now it is just confusing boilerplate. It's time to ditch it. <br>
<br>
It has been a regret that we didn't clean up the secondary effects of UseExceptions/DontUseExceptions a long time ago. I'm sure the original sin was a result of my mucking with the SWIG bindings to get something that kind of worked and giving up after that. I'm glad your PR addresses this and makes things better for other handler-aware code that is often mixed together with gdal.py such as Fiona/rasterio, QGIS bindings, or PDAL stuff (in my case). <br>
<br>
As for enabling them by default at our next 3.7 release ... one one hand, it has been fifteen years already and the project has been telegraphing through the options that this could/should change. On the other, GDAL is *very* conservative with API evolution, and making UseExceptions default behavior in the Python bindings breaks existing code that wasn't doing gdal.UseExceptions already. The nice thing about activating this behavior is that it causes it to throw an exception and tell the user about something that was otherwise silently failing, so the remedy in the case of most of these breakages is going to be clear. <br>
<br>
I would vote that we go for enabling UseExceptions by default for GDAL 3.7 based on the following assumptions:<br>
* The group that will feel the largest impact by the change is GDAL's own autotest suite<br>
* Exceptions are the Python Way, and default behavior of GDAL's bindings is out of step<br>
* Tons of user-land code is already doing UseExceptions, as it is a practice that is recommended in many tutorials and books and SE posts<br>
* The largest portion of GDAL-using Python developers are using Rasterio or Fiona, not gdal.py and ogr.py, and they would not be impacted by these changes (and maybe be impacted positively as the ticket describes).<br>
<br>
Are you a GDAL Python bindings user? Would you be impacted by this policy change? Please chime in.<br>
<br>
Howard<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank" rel="noreferrer">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>