Yes, someone on the forum is usually willing to take a look and offer pointers.

Bonus points if you have your code hosted somewhere like GitHub (plus, you'll learn about version control into the bargain).

Any newbie silly things that I am doing?

The function get_color() is one of the scariest things I have ever seen. Not because it does anything dangerous, per se, but because it relies on intimate knowledge of external state (i.e. what value you initialised the variable color to), and the name of the function gives no indication of this.

Since we are in python, I'd probably implement it more like this:

color, alternate = (255, 100, 0), (0, 128, 255) # assign both values by tuple unpacking
# ...
if (event.type == pygame.KEYDOWN and event.key == pygame.K_SPACE):
    color, alternate = alternate, color # swap values using tuple unpacking

Also I didn't understand what the get_image function is actually doing other than making the path os independent.

The get_image() function is mostly there to prevent you loading the same image twice. It caches every image you load in a dictionary (key'd with the file name), and if you try to load the same image file again, it will hand you the one it already loaded earlier.

I get that now but isn't it a little flawed? I mean shouldn't the canonical path be calculated before the first assignment to image variable. If it is done after that then actually there is no problem as the dictionary is updated with the same value but the image is loaded again.

If you look at it carefully, you'll note that even after deriving the canonical path, they still use the original (unchanged) path as the dictionary key.

It's a fair point that it might be better to use the canonical path as the key - at the very least, it would catch cases where the user passes in both the unix-style and windows-style paths at different times. That said, calculating the canonical path isn't free, so you might prefer to keep the current version, which is very fast in the already-loaded case.