On 22 September 2015 at 09:56, Stephen J. Turnbull <stephen@xemacs.org> wrote:
> Steven D'Aprano writes:
>
> > I wouldn't include punctuation [in the password alphabet] by
> > default, as too many places still prohibit some, or all,
> > punctuation characters.
>
> Do you really expect users to choose their own random passwords using
> this function? I would expect that this function would be used for
> initial system-generated passwords (or system-enforced random
> passwords), and the system would have control over the admissible set.
> But users who have to conform to somebody else's rules much prefer
> obfuscated passwords that pass strength tests to random passwords in
> my experience.
Right, the primary use case here is "web developer creating a default
password for an automatically created admin account" (for example),
not "end user creating a password for an arbitrary service".
We don't want to overgeneralise the canned recipes - keep them dirt
simple, and if folks want something slightly different, we can go the
itertools path and have recipes in the documentation.
Out of this whole proposal, this password function is the one I'm most worried about. As someone who has a project whose entire job is to generate consistent passwords, I can tell you it's a messy business that will just lead to never-ending complaints about "why didn't you include this as part of password alphabet" or "why did you choose that length". It just isn't worth the hassle when it isn't going to impact a majority of Python users. This can be something that web frameworks and other folks worry about.