Allow keyword arguments for digital pin setup #5124
Comments
|
Would also presumably obviate the need for the alternative 2nd step in the current flow: |
|
The most concise way to define a digital pin is currently 2 steps, not counting the imports. led = digitalio.DigitalInOut(board.LED)
led.switch_to_output(True) # LED is onbutton = digitalio.DigitalInOut(board.BUTTON)
button.switch_to_input(digitalio.Pull.UP)I have seen a couple of people on discord mention that they find the setup for pins in Circuitpython complicated (though they might think more of the 3-step version seen in many guides), and I tend to find it a little too verbose myself. In addition to require installing a library, simpleio's However, maybe it's too ambiguous to have the "input" or "output" direction of the pin be implicit in the use of keyword arguments (whereas It might be better to have something like DigitalIn/DigitalOut in the core, or in the form of helper functions that return a DigitalInOut like say |
|
I think this is not too hard: def __init__(
self,
pin: microcontroller.Pin,
*,
value: Optional[bool] = None,
pull: Optional[Pull] = None,
drive_mode: Optional[DriveMode] = None) -> None:If If I personally would rather not add |
|
Worth keeping mind that that we can "read" the value of an output: led.value = not led.value |
|
The reason we don't allow it from the constructor is that it's weird to have keyword arguments that are only valid depending on another (direction). Value and drive mode are for output and pull is for input. The class does default to input so we could add a pull kwarg. That'd simplify the input case. I'd push back against combining them. The other examples don't have this weird dependency between kwargs. |
|
Perhaps instead of setting My thought process says you'd have the following: So the argument would accept a boolean (For output values) or a pull direction (For input values), or default to how it works now. |
You still want to be able specify the I personally don't mind the keyword arguments depending on each other, because there are easy idioms for both the input and output cases. It's a deficiency of Python that it's painful to have multiple constructors: you can use class methods, but it's rare. |
|
My thoughts on it: |
|
I'll say this is subsumed by #9845. |
Uh oh!
There was an error while loading. Please reload this page.
As it sits right now, I can set up nearly any type of pin input and output in one line. I can, for example, use:
And this will start a PWM output that, on most boards, will turn the on-board LED on at half power. Similarly, AnalogIn and AnalogOut don't require any setup at all.
DigitalInOut, on the other hand, requires this, to largely accomplish the same thing:
It would be nice if we could do something like this:
Or, if you're doing an input:
It would definitely be nice to be able to start every pin in a single line, and importing another library just to do that seems a little excessive.
The text was updated successfully, but these errors were encountered: