[libcamera-devel] [RFC v3 0/5] Python bindings

[Laurent Pinchart]

Hi Tomi,

On Fri, Dec 10, 2021 at 02:16:40PM +0200, Tomi Valkeinen wrote:
> On 09/12/2021 18:44, Laurent Pinchart wrote:
> > On Thu, Dec 09, 2021 at 10:32:17AM +0000, David Plowman wrote:
> >> Hi Tomi, everyone
> >>
> >> Thanks for submitting this set, very pleased to see this moving again!
> >>
> >> I've actually been using these bindings extensively over the last
> >> several weeks, so we could add:
> >>
> >> Tested-by: David Plowman <david.plowman at raspberrypi.com>
> >>
> >> to all of them.
> >>
> >> A couple of points:
> >>
> >> * For my Picamera2 use cases (which are not remarkable) I had to add
> >> support for array controls, controls in the camera start() method, and
> >> an implementation of the transforms. I can submit those changes on top
> >> of this patch set at a later date, though they probably lack the
> >> requisite loveliness at the moment.
> >>
> >> * About the name "pycamera". Could we use "pylibcamera" instead? I
> >> worry that "pycamera" would cause more confusion with "picamera",
> >> which is of course our legacy stack Python library that Picamera2 is
> >> replacing.
> > 
> > One always loves a naming discussion.
> > 
> > Do we need the "py" prefix ? I would assume that a Python module can
> > safely be considered to be python-related, even with a "py" prefix :-)
> > We could then name the module "libcamera", "camera" or "cam" (the last
> > one may be a bit too short).
> 
> The binding generator currently builds "pycamera.so". I'm not sure if 
> creating a libcamera.so for both the libcamera library and the python 
> bindings will create problems. The bindings .so won't be in any common 
> lib directory, but I can imagine having interesting issues due to this.

"pycamera.so" sounds good to me, but as we have a __init__.py, maybe we
could store it in a "camera" directory, and import * from pycamera in
__init__.py (or something similar) ? PEP8 also recommends

"When an extension module written in C or C++ has an accompanying Python
module that provides a higher level (e.g. more object oriented)
interface, the C/C++ module has a leading underscore (e.g. _socket)."

(https://www.python.org/dev/peps/pep-0008/#package-and-module-names)

> I can give it a try.

-- 
Regards,

Laurent Pinchart