Python Code Challenges: Classes (Advanced). 2. Using The Superclass

What is this even asking me to do? I’m confused why its having me pass in new_sensor_range into the call later on when we aren’t adjusting that? Am I missing something here? also for a large chuck of endlessly running this it kept giving:

Traceback (most recent call last):
File “”, line 52, in
TypeError: adjust_sensor() missing 1 required positional argument: ‘new_sensor_range’

I finally just included 10 in the call:

why is it not defaulting to a previous sensor definition in the super class (and if it can’t why is answer code telling me to include new_sensor_range in the method definition!?)

It just doesn’t make any sense at all to me!

update: the answer code also fails and won’t let it pass. I had to do this instead

Override the adjust_sensor method here!

def adjust_sensor(self, sensor_range):   <- removed 'new_' from new_sensor_range
  super().adjust_sensor(sensor_range)   <- removed 'new_' from new_sensor_range
  self.obstacle_found = False
  self.step_length = 5

doing this worked but I’m not entirely sure why it worked or why new_sensor_range didn’t work

I might be mistaken but the only issue with your working is that you didn’t pass an argument to that call (hence the missing positional argument exception was raised and uncaught). I just tried with new_sensor_range in the new definition and it was fine. Not 100% sure what issue you caught but you seem to have the right logic in the end anyway :slightly_smiling_face:.

You don’t want to remove the ability to change the sensor_range, that’s why you’re using super (to keep the original behaviour) including an argument for a new sensor range. Changing the call signature of that method should be kept to a minimum (you can consider adding bits if necessary but avoid hiding the originals).

@tgrtim Thank you! I did try it again with just the new_sensor_range and it worked fine. I guess then I’m wondering why it was necessary to add that new_sensor_range in it anyways, is it because it already existed in the superclass so then also has to be included in the adjust_sensor(). these ones were particularly tough and I honestly don’t recall this being covered in the learning leading up to these challenges so I definitely felt a bit blindsided :flushed:

1 Like

So when you subclass you generally want to avoid changing any method too much (ideally you’d not override them at all). If your methods start taking completely new arguments, or worse still, removing existing ones then it should probably be using a different name since it’s obviously doing something different.

Consider your two methods at present, the basic premise behind a call to this method is to adjust the .sensor_range of an instance. At the moment they both have the same signature, this is clear and easy for any users of those classes.
Robot.def adjust_sensor(self, new_sensor_range): ... # original
WalkRobot.def adjust_sensor(self, new_sensor_range): ... #fix step length

If you suddenly bumped new_sensor_range from the parameter list the you’ve lost some of the functionality you used to have and basically laid a trap for any future users (how many arguments should I pass, why has it all changed?). In this particular example your new adjust_sensor method can’t even adjust the sensor_range defeating its original purpose.

I’m sure when you look at it this you can see how this would be bad practice.

Hopefully that makes sense at least, the whole thing drifts into design principles around OOP which is a fairly big topic and something to keep in mind for the future but I wouldn’t lose too much sleep about it until you’re more comfortable with classes in general.

1 Like

thank you! that helps a lot!

1 Like