Code review comment for lp:~apachelogger/desktopcouch/kwallet-support

IIRC python-keyring has at least on the KWallet side of things a desktop experience flaw because it will trigger authentication (to the wallet) for Python and not the particular app.
Eitherway I wanted it to be as non-intrusive as possible as to prevent regression.

The fact that it does look for kwallet and keyring is intentional since one user can run apps that try to access either backend, since the specification @ fdo does not go into any detail regarding multiple keyrings. In one implementation it is entirely possible that someone writes a KDE library that only accesses kwallet (which is entirely valid considering the spec says that one has to get the token from the keyring, but not any specific one or in any particular order), so if desktopcouch can access kwallet then it _must_ drop its token there (and technically any other keyring system it can find as to not limit client implementations).
If it did not do that then it sort of requires client implementations to search all keyring systems for tokens since desktopcouch might have dropped them in either of them.