On 17/11/2019 18:47, Dennis Lee Bieber wrote:
> On Sun, 17 Nov 2019 12:16:22 +0100, Tony van der Hoff 
> declaimed the following:
>
>>
>> BUT at present, RPi.GPIO fulfils my requirements very well. So, what is
>> the reason for deprecating it?
>
>  gpiozero:
>
> 1 allows use of alternate pin naming schemes without being locked into
> one mode
>
> 2 allows use of alternate low-level GPIO libraries (default is still
> RPi.GPIO, but if one sets it to use pigpio then one has the ability to have
> kernel/DMA based PWM rather than fully software based)
>
> 3 includes a module for a wide set of SPI-based MCPxxxx ADC chips, along
> with classes specific to servos, motors, etc.
>
> 4 has a 240 page manual -- RPi.GPIO has a short set of example usage.
>
> 5 Class-based (RPi.GPIO is just bare functions except for the PWM) -- one
> specifies the pin only when instantiating a class, and from then one uses
> methods of the instance; reduced risk of mistyping a pin number.
>
>

Right. I can see how gpiozero can bring some highly desirable benefits.
but that was not my question. A Dumbass stated:

Do. Not. Use. RPi.GPIO. Instead. Use. Gpiozero.

as if it was mandatory. All I wanted to know was why I *shouldn't* use
Rpi.GPIO. It appears to have been a false alarm. Sigh.

--- SoupGate-Win32 v1.05