[Python-ideas] Pre-PEP Adding A Secrets Module To The Standard Library

Nick Coghlan ncoghlan at gmail.com
Wed Sep 23 09:46:18 CEST 2015


On 23 September 2015 at 03:41, Tim Peters <tim.peters at gmail.com> wrote:
> [Steven D'Aprano <steve at pearwood.info>]
>> I too feel a quiet unease about password(), although I don't have
>> anything concrete to pin it on. I'm happy to be guided by people with
>> more experience in this realm.
>>
>> What if we called it simple_password() and made it clear that it wasn't
>> intended as an all-singing, all-dancing password generator?
>
> Just drop it.  Nobody I recall has said anything in favor of it ;-)

I think I may have been the one to suggest it originally, since one of
the things we're trying to address is the plethora of bad advice found
when Googling for "python password generator", but I'm OK with
dropping it from the initial version of the module, just on the
general principle that adding things later is relatively easy, while
taking them away is hard.

> It would be easy to give it as an example in the docs instead,
> building directly on choice().  That would steer people who need
> fancier stuff in the right direction.

Yeah, addressing the default password generation problem should work
just as well as a recipe in the secrets module documentation - I see
the core goal here as being to help guide folks towards using the
right random number generator for security sensitive tasks, and "use
the RNG in the secrets module for random secrets, and the RNG in the
random module for modelling and simulation" is a much easier story to
tell than explaining the technical differences between random.Random
and random.SystemRandom.

Raymond Hettinger's philosophy with itertools is likely a good guiding
principle here: provide a small set of useful primitives, and
otherwise favour recipes in the documentation. If we end up with a
"more-secrets" module on PyPI akin to "more-itertools", I think that's
fine (and also provides an easy way of backporting future secrets
module additions to earlier Python versions)

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list