Re: [libgpiod] python binding decidedly unpythonic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



pt., 13 wrz 2019 o 15:05 Darrien <darrien@xxxxxxxxxx> napisał(a):
>
> Hello,
>

Hi Darrien,

> I just started working with python3-libgpiod and noticed that it is
> decidedly unpythonic.
>

I'm not really sure what that means. A quick google search yields many
answers but not necessarily with regard to what should or should not
be handled as properties.

> For example the Line object functions active_state, consumer, direction,
> is_open_drain, is_open_source, is_requested, is_used, name, offset and
> owner should be properties, and set_value/get_value should be merged
> into one property.
>

For the first part: you may be right that it would be somehow "better"
or more standardized (I didn't really find any official documentation
that would suggest always using properties when possible - mostly some
stackoverflow posts), but I decided at the time of writing that when
in C, methods cause less churn. Also: these methods make the object
call underlying C code, so I considered it more of "telling the object
what to do". I may have been wrong - python is not my main language.

As for get/set values: this leads to execution of underlying code that
can fail, it's definitely not a property but an operation on the
object conceptually.

> Line.direction should probably also be writable for bidirectional pin use.
>

Definitely not. Direction can be changed by an external actor or by
the current process when it runs the request operation. Even as a
property it should be read-only.

> Regards
>
> Darrien
>

Let's say I'd want to convert the methods you listed to properties:
this would be a backward incompatible change of the interface. I'd say
it's the right thing to do if the API was fundamentally broken and
didn't work but it's not the case. I'd prefer not to force people to
change their existing code without a very strong reason.

In other words - if ever there'll be a change of API major version to
2, I'll be sure to address python bindings as well. For now I believe
we should leave it like it is.

Best regards,
Bartosz Golaszewski




[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux