[gdal-dev] VRT derived band pixel functions written in Python

[Even Rouault]

Le lundi 12 septembre 2016 16:59:34, Poughon Victor a écrit :
> Hi Even,
> 
> This is a really cool and really impressive feature!
> Calling Python code from C++ without development packages as a dependency
> sounds like black magic to me.

No black magic. Just setting function pointers using dlopen() :
https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/vrt/vrtderivedrasterband.cpp#L390

> Obviously Python symbols have to be there
> at some point to execute Python code, so this is only usable from a binary
> that happens to load them already (CPython, QGIS, etc.), correct?

No, there are 2 modes:
- GDAL is loaded after something else has already loaded python (so your 
CPython, QGIS)
- GDAL cannot find any python symbols in the already available symbols of the 
process, in which case it wil try to load a few reasonable shared objects like 
"libpython2.7.so", etc...

See 
https://github.com/OSGeo/gdal/blob/trunk/gdal/frmts/vrt/vrtderivedrasterband.cpp#L238 
and below lines

> But I'm confused because later you mention
> incompatibilities issues between the CPython and Pypy API. GDAL's secret
> sauce, I guess...?

Nothing GDAL specific here. It is just that the way to embed PyPy from C is 
completely different from CPython :

http://doc.pypy.org/en/latest/embedding.html
vs
https://docs.python.org/2/extending/embedding.html

> I'm also curious why it's possible to use numba but no
> pypy, which AFAIK are both python JITs?

numba is "just" a CPython extension (a non-trivial one dragging llvmlite 
etc...), so once you support CPython, it comes for free to use it, provided 
you use the right import and function decorations in your python code.

> And finally did you consider using
> Cython (which claims pypy compatibility)?

No, I didn't investigate that.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com