What's the best way to change, (overload), a pre-existing class, (i.e. a library class, or something like that?)

use_mutex=use_mutex - why did you do that, and why did you do that in that particular way?

1 Like

For sure - that is the intended purpose of putting that parm in the init definition.

99% of the users do not need mutex protection, so no need to waste the battery/processing load/execution time. “Stop Global Warming! Don’t Mutex Me!” :sunglasses: There may be a very, very tiny, tiny risk that the mutex can be left set by an exception at a bad time that might block all future GoPiGo3 execution requests. When I questioned this years ago, CleoQC mentioned they discussed this at length during the API design and decided on the default use_mutex=False.

The EasyGoPiGo3 class introduces the mutex protection around the GoPiGo3 class, and passes the parm to all the sensors, so that the sensors can be consistent with the super class protection level.

The My_EasyGoPiGo3 class definition def __init__( ... use_mutex=False): is creating a class parameter called use_mutex and setting a default if the parameter is not explicitly set in the instantiation request.

In that My_EasyGoPiGo3 initialization the call to the “super” (base class) initialization needs to “pass down” the value of that use_mutex parm, (either the default or the explicit value), to the EasyGoPiGo3 base class initialization.

my_egpg = My_EasyGoPiGo3(use_mutex=True)
→ passes use_mutex value into EasyGoPiGo3(use_mutex=use_mutex)
The use_mutex= is setting the use_mutex parameter of the EasyGoPiGo3 class initialization
The =use_mutex is referencing the value passed or defaulted in the My_EasyGoPiGo3 class initialization.

In the EasyGoPiGo3 class definition (easygopigo3.py):

        self.use_mutex = use_mutex    # saves the instantiation param as a class variable
        ...
        return easysensors.LightSensor(port, self, use_mutex=self.use_mutex)  # passed down to sensor initialization
        ...
        return easysensors.Servo(port, self, use_mutex=self.use_mutex)  # pass to servo init to ensure two processes do not try to command the servo at the same time
        ...

To keep themselves honest, DI has some mutex usage confirmation tests:

pi@Carl:~/Carl $ ls ~/Dexter/GoPiGo3/Software/Python/tests/
test_distance_sensor_2.py  test_distance_sensor.py  test_heavy_mutex_2.py  test_heavy_mutex.py  test_mutex.py  test_sensor_mutex.py

And I just found where you cannot use My_EasyGoPiGo3 derived from EasyGoPiGo3…
In easysensor.py:

  if not isinstance(gpg, gopigo3.GoPiGo3):
            raise TypeError("Use a GoPiGo3 object for the gpg parameter.")

isinstance would return easygopigo3.EasyGoPiGo3 as the class passed not gopigo3.GoPiGo3.

I knew it was somewhere, just had to re-find it.

2 Likes

That sounds bad.

Correct me if I am wrong, but what this is telling me is that if I “overload” the base class, then the sensors won’t work?  (i.e. They’ll throw an exception.) - right?

That almost sounds like a design flaw, (as opposed to a bug), because it deliberately forbids overloading the class.  Correct me if I am wrong, but one of the reasons for using a class is because it can be overloaded and necessary changes made without having to re-invent the wheel.

2 Likes

Right. That is what I kept saying.

The idea to protect is good, but needs an or case for bots that derive from the easygopigo3 class to allow for building over the easygopigo3 feature set.

But the existing code covers 99.99% of users!

2 Likes

Maybe this is a pull-request waiting to happen?

You should do this one, you’re more familiar with it.

Guess I’ll have to go back to using my modified library. Rats!  And I was having so much fun learning how to make classes and such work!

Having to re-write the library to do something like this seems so much like buying a new car because the tire’s flat.

1 Like

What? Ask DI to destabilize their codebase for two whiners that already have a solution? Where’s the profit?

2 Likes

Aren’t YOU the pessimist today. . .

Two people like us who care enough to want to improve things for them - without salary or benefits - sounds like a pretty sweet deal to me. :wink:

And just think, they get “global Forum response” without having to hire a call center in India.  Folks who post earlier get snagged by me; folks who post later on in the day get your help.  The only thing missing is some poor sod in Australia to cover the “third shift”. (double-wink!)

The advantage of being “unpaid” is the ability to tell everyone to “'naff-off” for a few days if you need a stress-break without having to beg your boss for the time off - a pretty sweet benefit AFAIAC.

2 Likes