Dependency hell is the situation where A depends on both B and C, but B depends on D, and C depends on D', where D and D' are not compatible.
Type classes absolutely do not create this kind of situation, as they are duck typing. But modules do create it, so it happens both on Haskell and on Python.
Now, in practice you use both, basic classes and library specific ones. And yes, if you want to create some behavior, you'll need to implement the specific code that enables it. You do not escape from that in Python either.
I know dependency hell when I see it. It's already bothersome if I can't just apt-get install the right library version because another package depends on a conflicting version, or the latest boost version isn't available yet. I refuse to learn tools like pip or stack for every language I use, and to create sandboxes for new projects only to get the latest library versions. That's just never going to be portable software.
You can actually escape dependency hell for most APIs. That's the Unix culture of using plain text (read: very simple data types -- in C that would be arrays and structures of integral types) for communication.
Of course that won't work for libraries that provide transformations on parameterized structures. But let's face it, there's no point in depending on a Monad library just to save two lines of pure code.
Type classes absolutely do not create this kind of situation, as they are duck typing. But modules do create it, so it happens both on Haskell and on Python.
Now, in practice you use both, basic classes and library specific ones. And yes, if you want to create some behavior, you'll need to implement the specific code that enables it. You do not escape from that in Python either.