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