I tend to use itemgetter because it's cleaner code than the lambda.

I'm happy with either solution. In most cases, I'd probably just use the lambda rather than itemgetter unless I knew I'd be working with a large dataset, but either way works fine. itemgetter turns out to be a little bit less expensive, time wise, and you only have to pay the import cost once, so I decided to run with that instead of the lambda.

itemgetter is always such a dilemma for it.
I like how clean and nice it is, but I almost never
use it because adding a whole import just for it feels silly,
especially since lambda x: x[n] is just as long anyway.

I've changed the requirements so that the resulting list should be returned from the function.

Cool. No worries ;P

OK wow, I'm not sure why I didn't see what you were saying about not actually doing anything with the ghost object being passed to eatGhost(). I've added a hash map for ghostCount and tests to check that eating a ghost will increase the count for total and color of the ghost eaten.

I also added language specific instructions for checking the values of ball and ghost objects.

Thanks a lot for the feedback!

It is not recommended to use a mutable data type such as a list as a default argument in python. It is also not very pythonic to send a result parameter that should be appended to. Instead, you generally see functions that return a list instead of modifying one passed in to it.

The first one isn't, but the other two are. You only show the default values in the example code.

I see you've now put some example code of how to test a ball's type. It seems from the code that the ball could have a ballType, ball_type or baller_type property (is that last one a typo?)... but my code still passes, and it only checks ballType. It might be easier (and more in keeping with a description rather than showing the implementation) to simply say: if the ball's type .ballType is "super"... Up to you how you word it, but this would be easier to understand, maybe?

As for the eatGhost thing, the reason I raised the question was because we don't use the ghost object for anything. We don't have to reference it whatsoever in the method to pass the kata. Maybe if we had to mark it as dead or not, that would give a good reason for it to be there?

I think the first 3 have been resolved. Please let me know, if not.

With regards to the eatGhost fufunctionthis was intended to be an exercise in object interaction, so it seemed natural. However, I'm very interested in why it wouldn't or shouldn't have a ghost object passed to it.

Do you think it would make more sense to try to eat a ghost and check if there is a ghost object to eat?

Have a look now, and please let me know if it makes more sense.

Cheers!

The way to check the ball type is in the language specific comments. However, since this same issue has come up so many times, I also added it in the description.

Instructions don't help with exact attribute names. It isn't clear what the attribute on the Ball class which contains the ball type should be and the attributes are described with spaces in them.