This worried me that there was a bug in passlib, so I tracked it down. Sadly the culprit seems to be that PHP's crazy "magic quotes" feature is mangling your passwords before wordpress hashes them.
Even if it's off in php.ini, wordpress may turn it on per-deployment by calling "wp_magic_quotes()" in wp-settings.php. It has the effect that a backslash is prepended to all ' " and \ characters in the POST parameter values, and Wordpress happily passes this on to it's phpass implementation without calling php's stripslashes()... so if your password is <<Foo"Bar>>, what actually gets hashed by Wordpress is <<Foo\"Bar>>. The Wordpress deploy I tested on apparently forbids \ in passwords... so
they knew there was something weird, but didn't investigate to much further. (IMHO this is horrible behavior, as a user whose password contains one of those characters will be unable to log in if the magic quotes setting is changed).
On the python side, if you run your password through...
import re
from passlib.hash import phpass
escaped_pwd = re.sub(r"""([\\'"])""", r"\\\1", pwd)
hash = phpass.encrypt(escaped_pwd, rounds=8)
... it should generate a hash that will work in your wordpress deploy.
Going forward, I'll have to think some more about how to handle this in passlib -- whether to just make a note in the documentation, or add some futher code to integrate the above solution in a way that doesn't break existing phpass hashes (e.g. from phpBB3 etc)
- Eli