digitalio.DigitalInOut constructor should accept direction

[rgov]

It would be nicer to write

pin = digitalio.DigitalOut(pin=board.GP123)

# or this
pin = digitalio.DigitalInOut(pin=board.GP123, direction=digitalio.Direction.OUTPUT)

# than this
pin = digitalio.DigitalInOut(pin=board.GP123)
pin.switch_to_output()

"Explicit is better than implicit." Defaulting to input seems arbitrary and it would be better for code to be explicit about direction. And it makes it a one-liner to define an output pin, which is nice if you're doing many of these.

Note analogio differentiates AnalogIn and AnalogOut which is also very readable.

[tannewt]

We didn't do this because there are different pin settings for input vs output mode. Pull is only valid for input for example. Having direction in the constructor would require cross parameter validation (if pull is set but direction is output then fail.)

[rgov]

Seems like that's an argument for splitting DigitalIn and DigitalOut so that there is less complexity in what combination of settings are allowed?

[dhalbert]

Sometimes you want to switch a pin from input to output or vice versa and then back again. For instance this is useful when scanning keyboard matrices. We are thinking in the long run about separating pin I/O state from pin functionality. For instance, you'd create a "Pad" or some name like that on a given pin. Then you could control its I/O state (pulls, open-collector output, drive strength), and pass that around to DigitalInOut, busio.whatever, etc., rather than simply passing a pin name. Or perhaps you could pass DigitalInOut as well as pins to such classes.