Why the author made the code worse, commit by commit:

1. Harmful and degrades the readability of the code. Inline constants like that are just as bad as global variables, and there's now a giant refactor danger in the code from people (a) reimplementing this constant and (b) not updating the original one, if it becomes used in more than one place. Neither solution is great, here, but this is game data that should not be expressed in code; it should, ideally, be in some kind of asset.

Additionally, this is a judgment call, but I feel that adding whitespace to line up the color constants violates the spirit of PEP 8, if not the letter:

http://www.python.org/dev/peps/pep-0008/#whitespace-in-expre...

2. Magic numbers are bad. Littering the file with SHOUTING constants is worse. As with the powerups from item 1, move this to a configuration of some kind rather than expressing it in code.

3. Docstring immediately violates PEP 8 by being 83 characters long (for a total of 89 including quotes).

http://www.python.org/dev/peps/pep-0008/#maximum-line-length

Additionally, the docstring regurgitates what the code does without explanation, which is entirely pointless. Docstrings must explain what I cannot infer from reading the declaration and implementation. At least it mentioned the return type, which is good.

Do not refactor someone else's code and change their indentation style because it fits your preference. That's just being argumentative, and unproductive. There's a reason that PEP 8 says for new projects in this guidance:

http://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

4. Multiple PEP 8 violations as in item 3.

http://www.python.org/dev/peps/pep-0008/#maximum-line-length

5. Direct assault on readability that has no purpose. The original mistake was shorthanding 'pos'. Your code should tell me exactly what is going on, and the author admitting "it means either position or positive" is a clue that this is the wrong tactic.

6. Fine.

7. Fine.

8. Fine.

9. The addition of the conditional does not make the call simpler, and the author has now introduced two calls to random() instead of one. Although the original implementation of random_position() can certainly be improved, this change makes it worse in potentially performance-important code. (Clearly it isn't, but better to make things more efficient than less. A conditional and two random() calls is far less efficient than some math.)

10. Fine.

11. Now we're into blatant violations of the whitespacing from PEP 8 I alluded to earlier:

http://www.python.org/dev/peps/pep-0008/#whitespace-in-expre...

We're also expressing configuration as code again, and instantiating a dictionary to express that configuration every time the factory is called.

12. --amend your commits. There's absolutely no excuse for pushing a busted Git commit message aside from not knowing how to use your tools.

Line 130 through 135 contain newlines for absolutely no reason; I don't understand why these were necessary.

There are string comparisons in this commit for the kind of an object; string comparisons to describe something programmatic are the least-efficient way to reflect program state.

The author is going back on something he chastised the original author for earlier, and using 0.03 directly in code AS A MAGIC CONSTANT which he said never to do (line 162)!

13. More PEP 8 violations. The author then documented his magic constant on line 164 because he realized it's unreadable, but didn't bother to fix it.

I'm giving up at this point.