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