[libgpiod] python binding decidedly unpythonic

[libgpiod] python binding decidedly unpythonic

[Darrien]

Hello,

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

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.

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

Regards

Darrien

Re: [libgpiod] python binding decidedly unpythonic

[Bartosz Golaszewski]

sob., 14 wrz 2019 o 10:42 Bartosz Golaszewski <brgl@bgdev.pl> napisał(a):
>
> pt., 13 wrz 2019 o 15:05 Darrien <darrien@freenet.de> 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

We discussed the python bindings off list with Darrien and he
convinced me that it's worth improving them and doing it earlier will
impact less people. At the same time I don't want to break the
existing, already released interface. The plan is to implement a new
module with the API that is more 'pythonic' and converting the current
gpiod module into a compatibility layer that will be deprecated over
time and eventually removed. This isn't however going to happen very
soon as I'm busy with other things ATM and also I'd really like to get
this right this time.

Bart

Re: [libgpiod] python binding decidedly unpythonic

[Bartosz Golaszewski]

pt., 13 wrz 2019 o 15:05 Darrien <darrien@freenet.de> 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

[libgpiod] python binding decidedly unpythonic

[Darrien]

Hello,

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

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.

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

Regards

Darrien