text: python-keyring is seriously nice
  Many programs require passwords from the user.
  It's nice when a program can remember the password you give it.
  It's nicer when it stores said password safely. However, it's not trivial to do that if you care for cross-platform support.
  Or at least it wasn't until Kang Zhang wrote python keyring, a module that abstracts the password storage mechanisms for KDE, GNOME, OSX and windows (and adds a couple of file-based backends just in case).
  So, how does it work?
  Install it in the usual way. If it's not packaged for your distro/operating system, just use easy_install:
  easy_install keyring
  You could also get it from mercurial:
  hg clone
  The API is simplicity itself. This is how you save a secret:
  import keyring keyring.set_password('keyring_demo','username','thisisabadpassword')
  You may get this dialog (or some analog on other platforms):
  And here's the proof that it was saved correctly (this is KDE's password manager):
  And how do you get the secret back?
  import keyring print keyring.get_password('keyring_demo','username')
  This is how it runs:
  $ python load.py thisisabadpassword
  As you can see, the API is as easy as it could possible get. It even chose the KWallet backend automatically because I am in KDE!
  Python-keyring is a module that fixes a big problem, so a big thank you to Kang Zhang and Tarek Ziadé (who had the idea)
  Python-keyring is available on Debian, should be available in Ubuntu in ... some months I guess.
  It's also available in Arch.
  Thanks for the link
  Using python is a bit of a silly idea; I can see a virus searching for your python app in your homedir and modify it to email all passwords it can harvest from the kwallet (since the user gave it an 'ok its safe!').
  This may even be the case if the python stuff is installed as root, simply because its easy to place new python code in your homedir and make it be executed instead of the packages-installed app.
  And the same problem happens; the user gives an ok because the user is unable to detect the difference.
  I seriously think using any scripting language is just wrong for this kind of work.
  The "app X is asking for permission to open wallet" is trivial to overcome, since the app name is simply a parameter in QApplication construction.
  If you are depending on that for your security, you are screwed.
  It *may* be non-trivial if kwallet (or gnome-keyring) checked whih process is asking, looked for the binary location via /proc and refused to work if it's not a system binary, but even that kinda sucks in other ways.
  Perhaps if the wallet stored an MD5 for the approved application this scenario could be handled. I think the majority of python apps would be installed through package management which means the virus would need root privileges to modify them anyway.
  Yes, MD5 sums would increase security from a technical point of view. The application name alone is quite insufficient. For instance in Gnome you could write a malicious app which calls gobject.set_application_name("trusted_app") and then inherits the rights of "trusted_app" (correct me if I'm wrong).
  Anyway, in daily use MD5 sums would fail too. Consider some packaged application which gets updated regularly. Each time the question "Application X is requesting access to ..." would reappear and users would tend to blindly acknowledge, also because they mostly cannot decide if the MD5 change has been caused by a regular package update or by hijacking the application name.