Re: [Python-ideas] [Python-Dev] Proposal for the getpass module

[redirecting to python-ideas] On Sat, Feb 6, 2010 at 4:08 PM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
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'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. -- --Guido van Rossum (python.org/~guido)

On Sun, Feb 7, 2010 at 1:30 AM, Guido van Rossum <guido@python.org> wrote:
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
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. Tarek -- Tarek Ziadé | http://ziade.org

On Sat, Feb 6, 2010 at 4:42 PM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
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.)
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)

On Sun, Feb 7, 2010 at 2:27 AM, Guido van Rossum <guido@python.org> wrote: [..]
I agree. Make sense now
When you register or upload a package to PyPI, you have two choices. Either you store your password in clear text in your pypirc file, either you type it at the prompt, through a getpass() call. The use case is to be able to store it in a safe place rather than in clear in a config file.
Maybe the new API should just be a utility in distutils?
Sounds like the solution. Although some people might use it to interact with a Keyring without necessarily being in the context of using Distutils, that's why I was targeting a module oustide distutils in the stdlib. Regards, Tarek -- Tarek Ziadé | http://ziade.org

On Sun, Feb 7, 2010 at 1:30 AM, Guido van Rossum <guido@python.org> wrote:
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
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. Tarek -- Tarek Ziadé | http://ziade.org

On Sat, Feb 6, 2010 at 4:42 PM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
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.)
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)

On Sun, Feb 7, 2010 at 2:27 AM, Guido van Rossum <guido@python.org> wrote: [..]
I agree. Make sense now
When you register or upload a package to PyPI, you have two choices. Either you store your password in clear text in your pypirc file, either you type it at the prompt, through a getpass() call. The use case is to be able to store it in a safe place rather than in clear in a config file.
Maybe the new API should just be a utility in distutils?
Sounds like the solution. Although some people might use it to interact with a Keyring without necessarily being in the context of using Distutils, that's why I was targeting a module oustide distutils in the stdlib. Regards, Tarek -- Tarek Ziadé | http://ziade.org
participants (2)
-
Guido van Rossum
-
Tarek Ziadé