Q:

Should I check the types of constructor arguments (and at other places too)? 

Python discourages checking the types.  But in many cases this may be useful:

Checking constructor arguments.  e.g. checking foe Boolean, string, dict etc.  If I don't and set the object's members to the arguments it will cause problems later. 
Checking functions arguments. 
In properties.  If someone sets a wrong value or different type, I should respond quickly. 

A:

The simple answer is No, use Polymorphism, Exceptions etc.  

In the case of constructor arguments being of the wrong type, an exception will be thrown when executing code that depend s on the parameter being of a particular type.  If it is a weird, domain specific thing, raise your own Exception.  Surround blocks of code which are likely to fail with try-except and handle errors.  So it is better to use Exception handling. ( Same goes for function arguments)
In properties, the same argument applies.  If you are validating the value received, use an assertion to check its range etc.  If the value is of the wrong type, it will fail anyway.  Then, handle AssertionError. 

In Python, you treat programmers as intelligent beings!!  Just document your code well (make things obvious), raise Exceptions where appropriate, write polymorphic code etc.  Leave the Exception handling(where it is appropriate only)/errors in construction to the client code. 
Warning
Leaving Exception handling to clients doesn't mean that you should chuck a lot of garbage errors at the unwitting user.  If at all possible, handle exceptions that might occur due to bad construction or any other reason in your code itself.  Your code should be robust.  Where it is impossible for you to handle the error, politely inform the user/client code programmer! 
Note
In general, bad arguments to a constructor isn't something I worry about too much. 

A:

The answer is almost always "no".  The general idea in Python, Ruby, and some other languages us called "Duck Typing".  You shouldn't care what something is, only how it works.  In other words, "if all you want is something that quacks, you don't need to check that it's actually a duck." 
In real life, the problem with putting in all those type checks is the inability to replace inputs with alternate implementations.  You may check for dict, but I may want to pass something in which is not a dict, but implements the dict API. 
Type checking only checks for one of many possible errors in code.  For example, it doesn't include range checking (at least not in Python).  A modern response to the assertion that there needs to be type checking is that it's more effective to develop unit tests which ensure that not only are the types correct, but also that the functionality is correct. 
Another viewpoint is that you should treat your API users like consenting adults, and trust them to use the API correctly.  Of course there are times when input checking is helpful, but that's less common than you think.  One example is input from untrusted sources, like from the public web. 

A:

Check all you like, you just have to be explicit.  The following example is a constructor from a module in the standard library - it checks the extrasaction arg:
class DictWriter:
  def __init__(self, f, fieldnames, restval="", extrasaction="raise",
               dialect="excel", *args, **kwds):
      self.fieldnames = fieldnames    # list of keys for the dict
      self.restval = restval          # for writing short dicts
      if extrasaction.lower() not in ("raise", "ignore"):
          raise ValueError, \
                ("extrasaction (%s) must be 'raise' or 'ignore'" %
                 extrasaction)
      self.extrasaction = extrasaction
      self.writer = writer(f, dialect, *args, **kwds)

