Properties look like normal member variables, and give false feeling that they're are fast and cheap to access. A sensor may be on slow bus like I2C, require big block of data to transfer, and then slow floating-point calculations to get real-world units. All that may be very slow, which you may have no idea about and use "sensor.temperature" 10 times in row. If it's method call, it's pretty natural to think that it has its cost, and that value may need to be cached.pythoncoder wrote:Firstly there seems to be a cost in terms of RAM usage and performance. Secondly accessing a property can trigger code execution which isn't evident to the caller, whereas accessing a method evidently leads to code running.
I'll bow to Damien and Paul's expertise on the first point. I'm only partly convinced by the second - triggering execution is, after all, the purpose of properties - but I'm willing to go along with the convention in future.
Properties also require deep searches for lookup, so super-efficient ports may simply disable properties support, we want to design API which works even for them.
If that all still doesn't ring a bell, let me say it like this: we don't want to limit MicroPython-based battery-powered sensors to 1 year of battery life due to uncareful design of API, if otherwise 3 years are achievable. (It's hard to quantify the numbers, so well, we're just staying on conservative side and avoid using things which are known to be less efficient than the other).