Home Original page

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

Guido van Rossum guido at python.org
Sun Feb 7 02:27:21 CET 2010 
On Sat, Feb 6, 2010 at 4:42 PM, Tarek Ziadé <ziade.tarek at gmail.com> wrote:
> On Sun, Feb 7, 2010 at 1:30 AM, Guido van Rossum <guido at 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)
More information about the Python-ideas mailing list