[Jtsummers]

Except grabbing types like that in code is usually a code smell. It can become brittle and hard to extend as time goes on. It's suitable when you need something now or you know you'll only ever have a few (less than 4 or 5, preferably no more than 2) cases. But either way you ought to be refactoring to something more like the third example.

[sevensor]

Well, calling type() is usually bad, isinstance() is a little better. But if you're expecting a ThisClass and only falling back on strings, as implied by the example, surely this is the classic example of where duck typing is handy:

    try:
        processObject(value)
    except ValueError:
        processString(value)        

Where you've written processObject so that it only works on duck-like objects:

    def processObject(value):
        try:
            value.quack()
        except AttributeError:
            raise ValueError('I was expecting something like a duck!')

[meuk]

Personally, I consider code I don't understand after reading it thrice a much worse code smell.

Less sarcastically: I think you're being too dogmatic. I don't like the idea of 'code smells', because it encourages you to judge code not by performance, maintainability, or readability, but by the property that someone has decided it's a code smell. Often it's true that the pattern can be used to write utterly shit code. Code smells are, IMHO, being used as a substitute for common sense. My common sense tells me that the first example is most clean solution. If the code keeps you from obtaining the performance you need, or if you add more checks in other places which make the code unreadable, by all means, refactor it.