Question: Is it common in Python to keep testing for type values when working in a OOP fashion?

```
class Foo():
    def __init__(self,barObject):
        self.bar = setBarObject(barObject)

    def setBarObject(barObject);
        if (isInstance(barObject,Bar):
            self.bar = barObject
        else:
            # throw exception, log, etc.

class Bar():
    pass

```

Or I can use a more loose approach, like:

```
class Foo():
    def __init__(self,barObject):
        self.bar = barObject

class Bar():
    pass

```

Answer: 
I think that it's good practice to check *input* for type. It's reasonable to assume that if you asked a user to give one data type they might give you another, so you should code to defend against this.

However, it seems like a waste of time (both writing and running the program) to check the type of input that the program generates independent of input. As in a strongly-typed language, checking type isn't important to defend against *programmer error*.

So basically, check input but nothing else so that code can run smoothly and users don't have to wonder why they got an exception rather than a result.
If your alternative to the type check is an else containing exception handling, then you should really consider duck typing one tier up, supporting as many objects with the methods you require from the input, and working inside a try.
You can then except (and except as specifically as possible) that.
The final result wouldn't be unlike what you have there, but a lot more versatile and Pythonic.

Everything else that needed to be said about the actual question, whether it's common/good practice or not, I think has been answered excellently by David's.