This function detects if a gameobject has moved or has had its sprite changed. It then calls one of two functions (or none), to draw a piece of the games background over the gameobjects current location or previous location. Should functions like this be avoided? Is this good or bad design? Does it violate SRP?

Also, how would something like this be unit tested?

#clean up the display...
def blit_background_over_dirty_rects(self):
		for gameobject, data in self.relevant_data.items():
			if data['location'] != gameobject.rect.topleft: #gameobject moved...
				self._blit_background_over_gameobjects_previous_location(gameobject)
			elif data['sprite'] != gameobject.sprite_manager.current_sprite: #gameobjects sprite changed...
				self._blit_background_over_gameobjects_current_location(gameobject)

Code calls other code all the time.  That by itself is not an issue.

However, usually code should follow commands that do a bunch of work rather than micromanage the details of the work.  In your case it is probably faster to redraw everything with a single render command rather than to check every single object for details of if it happened to move.

Perhaps you should look into the 4 principles of OOPs ( object oriented programming)

Agreed with frob.

It's quite normal for a function to call other functions.  We build functions to accomplish specific tasks and then put them together to create more complicated things happen.  If functions didn't call other functions it would be very difficult to compose complex programs in a nice way.

However, your specific design seems a little odd in this case.  Rather than each object updating and redrawing itself, you would more commonly update the logical position of all items (or all items within view if you've gotten far enough to be managing things off screen as well), and then redraw the entire screen with all objects in their updated positions.

Is redrawing the entire screen every frame the common approach? Even if there are areas on the display that haven't changed? I'm using Pygame and I've read that you should only redraw the area of the screen that has been changed for performance reasons, though I'm not sure if this is unique to Pygame or even relevant to to Pygame anymore.

OOP and Functional Programming are two different approaches to solving problems. OOP is just all the rage right now. What you are describing sounds like Functional Programming. You can read about it here:

http://www.codenewbie.org/blogs/object-oriented-programming-vs-functional-programming

I'm not a graphics expert but as far as I know most graphics APIs flip between two pieces of memory...the visible 'buffer' that is being rendered and the back 'buffer' that is redrawn all the time. When the API is done drawing on the back buffer it cycles the back buffer to the visible buffer. So point being...as long as you are redrawing the back buffer probably no issue.

13 hours ago, mrpeed said:

Is redrawing the entire screen every frame the common approach? Even if there are areas on the display that haven't changed?

Yes.

13 hours ago, mrpeed said:

 I'm using Pygame and I've read that you should only redraw the area of the screen that has been changed for performance reasons

This is because Pygame is based on ancient technology that is embarrassingly out of date.

13 hours ago, mrpeed said:

I'm not sure if this is unique to Pygame or even relevant to to Pygame anymore

Pygame is one of the only systems that expects to draw to the screen using old technology. Pygame uses SDL 1.2.  SDL.1.2 uses DirectX 5, specifically DirectDraw for graphics. DirectX 5 is literally 20 years old, written for a time when a typical screen was 640x480 and graphics cards were esoteric add-on units.