On Sat, Feb 6, 2010 at 4:42 PM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
On Sun, Feb 7, 2010 at 1:30 AM, Guido van Rossum <guido@python.org> wrote:
[redirecting to python-ideas] [..]
Don't you usually have to tell the keyring which password to retrieve? The signature for getpass() doesn't have enough info for that.
I've slightly changed the signature to add two new options:
- service : the name of the service the password is associated to (defaults to 'Python') - username: the name of the user (defaults to the value returned by getpass.getuser() )
These options are not used by the existing functions, but make it possible for a keyring API to handle the request properly by getting the password stored for service+username
You really need to think of this as adding a new API whose default behavior is to call the original getpass() function. I don't see any advantage to giving this function the same name as the classic getpass() -- the default of getting a password named "Python" is unlikely to be useful. (If you disagree, please provide a real use case.)
I'm not sure that not adding a new module to the stdlib is a sufficient reason to foist the new semantics on an old function.
I've done it this way so the "Distutils calls getpass" use case would work transparently, but maybe it's a bad idea to add a hook like that after all. Maybe a new API for this would be better, with a dummy implementation in the stdlib and a way to configure an external tool to be used.
What's this use case? What password does distutils need to ask for? Maybe the new API should just be a utility in distutils? -- --Guido van Rossum (python.org/~guido)