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

[Tarek Ziadé]

On Sun, Feb 7, 2010 at 2:27 AM, Guido van Rossum <guido at python.org> 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.)

I agree. Make sense now

>
>>> 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?

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