Hi Petr,

The API you proposed here comes is similar to something I see a lot in MicroPython libraries: functions/methods that combine a getter and setter. For example, to set the value on a pin, you do: pin.value(1) and to read, you do: result = pin.value()

If an API like this was added to the stdlib, I'd expect it to use a property, e.g. pin.value = 1 result = pin.value

I was wondering, what's the story of this aspect of MicroPython API? Does it have hidden advantages? Were you inspired by another library? Or was it just the easiest way to get the functionality (I assume you implemented functions before properties), and then it stuck?

Yes we do use this pattern a fair bit for things that are property-like, eg machine.freq() to get and machine.freq(42000000) to set the CPU frequency.

The history reaches back to this issue: https://github.com/micropython/micropython/issues/378 . The main thing is that (for example) setting a frequency is a real action (a function if you will) that is doing lots of things behind the scenes, and which may fail with an exception. It therefore doesn't feel right to make this an attribute, but rather a proper function.

To me, an attribute should only be used for things that are true constants, or that are conceptually just a "member variable of an object", to which you can assign any value, and reading it back gives you the same value.

So, that's the rationale behind using functions.

Cheers, Damien.