[gdal-dev] Python bindings: enabling exceptions by default?

[Kurt Schwehr]

We are heavy users of the swig bindings. We have some Fiona users and are
only just now in the process of starting to use rasterio. We have only 3
instances of calling UseExceptions. Turning on UseExceptions
immediately blew up a bunch of my tests that were making incorrect
assumptions. Nothing major, but I haven't looked for more than a couple
seconds for trouble.

+1 for switching to have it enabled by default. I'm not sure if it would be
better with 3.7.0 or 4.0.0.

On Mon, Mar 20, 2023 at 10:58 AM Howard Butler <howard at hobu.co> wrote:

>
>
> > On Mar 19, 2023, at 7:34 AM, Even Rouault <even.rouault at spatialys.com>
> wrote:
> >
> > Hi,
> >
> > I've prepared a pull request that does the above, but this raises a
> number of questions. See my longish comment at
> https://github.com/OSGeo/gdal/pull/7475#issuecomment-1475239852. Thoughts
> appreciated
>
> First off, thank you for doing this.
>
> Speaking for myself, pretty much all of the ogr.py/gdal.py 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.
>
> 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).
>
> 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.
>
> I would vote that we go for enabling UseExceptions by default for GDAL 3.7
> based on the following assumptions:
> * The group that will feel the largest impact by the change is GDAL's own
> autotest suite
> * Exceptions are the Python Way, and default behavior of GDAL's bindings
> is out of step
> * 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
> * 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).
>
> Are you a GDAL Python bindings user? Would you be impacted by this policy
> change? Please chime in.
>
> Howard
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20230320/a02397de/attachment.htm>