Adding type constraint checks to dynamic languages is not "horrifying". It's merely using the language to extend the language; where you want type checks, you can have type checks.

It's pretty horrifying from a performance perspective.

It's pretty nice from a correctness perspective. If you cared about performance, you would not be using Python (or Ruby, or Perl).

If you cared about type constraints you would not be using Python (or Ruby, or Perl).

Far more interesting (IMO), would be a constrains based library based on predicates (iterable, hashable, arithmatic-able?)

In ruby you can ensure this by calling responds_to?(:method).

So for example to see if some object is iterable, you just check if it responds to each.

   obj.responds_to?(:each)

That doesn't guarantee that "each" is actually the right "each".

Just because you are using python doesn't mean that you have no interest in performance. Most apps don't need to be as fast as possible, but only fast enough. Adding a bunch of stuff that slows down python will decrease the set of problems where python is fast enough and thus usable. A large app I recently worked on is a python app interacting with a bunch of C++ libraries. The faster I could make my python code the more I can move stuff from C++ to python, which greatly decreases the time it takes to develop and change the app.

I will concede this point. Well put.

This was interesting to me. I'm learning Haskell right now, after using Python as my main prototyping / glue / tools language (I get paid to write in C++ and Objective-C).

The horrifyingly broken performance of the Python Global Interpreter Lock (GIL) on multi-core has me looking for an alternative for performance-sensitive higher-level code.

Typically I experiment with a new higher-level language, and then fall back on "I'll meta-program in the high-level language, and emit portable C code." Sigh.