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 <how...@hobu.co> wrote: > > > > On Mar 19, 2023, at 7:34 AM, Even Rouault <even.roua...@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@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev