10. Backwards Compatibility

GPIO Zero 2.x is a new major version and thus backwards incompatible changes can be expected. We have attempted to keep these as minimal as reasonably possible while taking advantage of the opportunity to clean up things. This chapter documents breaking changes from version 1.x of the library to 2.x.

10.1. Python 2.x support dropped

By far the biggest and most important change is that the Python 2.x series is no longer supported (in practice, this means Python 2.7 is no longer supported). If your code is not compatible with Python 3, you should follow the porting guide in the Python documentation.

As of GPIO Zero 2.0, the lowest supported Python version will be 3.5. This base version may advance with minor releases, but we will make a reasonable best effort not to break compatibility with old Python 3.x versions.

10.2. RPIO pin factory removed

The RPIO pin implementation is unsupported on the Raspberry Pi 2 onwards and hence of little practical use these days. Anybody still relying on RPIO’s stable PWM implementation is advised to try the pigpio pin implementation instead (also supported by GPIO Zero).

10.3. Deprecated pin-factory aliases removed

Several deprecated aliases for pin factories, which could be specified by the GPIOZERO_PIN_FACTORY environment variable, have been removed:

• “PiGPIOPin” is removed in favour of “pigpio”
• “RPiGPIOPin” is removed in favour of “rpigpio”
• “NativePin” is removed in favour of “native”

In other words, you can no longer use the following when invoking your script:

$ GPIOZERO_PIN_FACTORY=PiGPIOPin python3 my_script.py

Instead, you should use the following:

$ GPIOZERO_PIN_FACTORY=pigpio python3 my_script.py

10.4. Keyword arguments

Many classes in GPIO Zero 1.x were documented as having keyword-only arguments in their constructors and methods. For example, the PiLiter was documented as having the constructor: PiLiter(*, pwm=False, initial_value=False, pin_factory=None) implying that all its arguments were keyword only.

However, despite being documented in this manner, this was rarely enforced as it was extremely difficult to do so under Python 2.x without complicating the code-base considerably (Python 2.x lacked the “*” syntax to declare keyword-only arguments; they could only be implemented via “**kwargs” arguments and dictionary manipulation).

In GPIO Zero 2.x, all such arguments are now actually keyword arguments. If your code complied with the 1.x documentation you shouldn’t notice any difference. In other words, the following is still fine:

from gpiozero import PiLiter

l = PiLiter(pwm=True)

However, if you had omitted the keyword you will need to modify your code:

from gpiozero import PiLiter

l = PiLiter(True)  # this will no longer work

10.5. Robots take Motors, and PhaseEnableRobot is removed

The GPIO Zero 1.x API specified that a Robot was constructed with two tuples that were in turn used to construct two Motor instances. The 2.x API replaces this with simply passing in the Motor, or PhaseEnableMotor instances you wish to use as the left and right wheels.

If your current code uses pins 4 and 14 for the left wheel, and 17 and 18 for the right wheel, it may look like this:

from gpiozero import Robot

r = Robot(left=(4, 14), right=(17, 18))

This should be changed to the following:

from gpiozero import Robot, Motor

r = Robot(left=Motor(4, 14), right=Motor(17, 18))

Likewise, if you are currently using PhaseEnableRobot your code may look like this:

from gpiozero import PhaseEnableRobot

r = PhaseEnableRobot(left=(4, 14), right=(17, 18))

This should be changed to the following:

from gpiozero import Robot, PhaseEnableMotor

r = Robot(left=PhaseEnableMotor(4, 14),
          right=PhaseEnableMotor(17, 18))

This change came about because the Motor class was also documented as having two mandatory parameters (forward and backward) and several keyword-only parameters, including the enable pin. However, enable was treated as a positional argument for the sake of constructing Robot which was inconsistent. Furthermore, PhaseEnableRobot was more or less a redundant duplicate of Robot but was lacking a couple of features added to Robot later (notable “curved” turning).

Although the new API requires a little more typing, it does mean that phase enable robot boards now inherit all the functionality of Robot because that’s all they use. Theoretically you could also mix and match regular motors and phase-enable motors although there’s little sense in doing so.

The former functionality (passing tuples to the Robot constructor) will remain as deprecated functionality for gpiozero 2.0, but will be removed in a future 2.x release.