These can still be viewed on the full Motor class description. But on EV3, these functions are not so relevant as all motors have encoders.
Then we can also remove the encoded/encoderless rubric, further removing clutter.
Instead, show shorter, simpler Motor docs platform-devices pages. For the moment, this just means deleting the advanced methods section from those pages, but we may choose to simplify further.
This change makes it easier to navigate the ev3devices/pupdevices pages because the motor sections aren't overly long.
Details will still be available on the Motor pages for those who wish to use the more advanced motor capabilities such as adjusting the PID settings.
This makes the user code easier to read:
brick.buttons()
brick.buttons.pressed()
It also opens up possibility to add features in the future such as:
brick.buttons.released() # return which buttons are not pressed
brick.buttons.clicked() # return which buttons were clicked since we last checked
This follows the same style as the new light API: some devices have specific instances of a KeyPad class.
A good example that nicely demonstrates the concept is the LPF2 RemoteControl, which has instances of a ColorLight and a KeyPad. It's added in this commit.
Same result as in 92e3735d63, but now achieved by patching the Sphinx configuration instead of patching the API.
Now it doesn't break the API for the purpose of checking and autocomplete, etc.
This is an experimental method for adding lights to some sensors.
And add workaround to make it show up correctly in the docs.
Also some doc8 formatting
Laurens Valk
David Lechner