<p dir="ltr">Yes 'secrets' is one-liners. However, it might grow a few more lines around the blocking in getrandom() on Linux. But still, not more than a few.</p>
<p dir="ltr">But the reason it should be on PyPI is so that programs can have a uniform API across various Python versions. There's no real reason that someone stick on Python 2.7 or 3.3 shouldn't be able to include the future-style:</p>
<p dir="ltr">import secrets<br>
Answer = secrets.token_bytes(42)</p>
<div class="gmail_quote">On Jun 16, 2016 4:53 PM, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 16 June 2016 at 13:09, Barry Warsaw <<a href="mailto:barry@python.org">barry@python.org</a>> wrote:<br>
> On Jun 16, 2016, at 01:01 PM, David Mertz wrote:<br>
><br>
>>It seems to me that backporting 'secrets' and putting it on Warehouse would<br>
>>be a lot more productive than complaining about 3.5.2 reverting to (almost)<br>
>>the behavior of 2.3-3.4.<br>
><br>
> Very wise suggestion indeed.  We have all kinds of stdlib modules backported<br>
> and released as third party packages.  Why not secrets too?  If such were on<br>
> PyPI, I'd happily package it up for the Debian ecosystem.  Problem solved<br>
> <wink>.<br>
<br>
The secrets module is just a collection of one liners pulling together<br>
other stdlib components that have been around for years - the main<br>
problem it aims to address is one of discoverability (rather than one<br>
of code complexity), while also eliminating the "simulation is in the<br>
standard library, secrecy requires a third party module" discrepancy<br>
in the long term.<br>
<br>
Once you're aware the problem exists, the easiest way to use it in a<br>
version independent manner is to just copy the relevant snippet into<br>
your own project's utility library - adding an entire new dependency<br>
to your project just for those utility functions would be overkill.<br>
<br>
If you *do* add a dependency, you'd typically be better off with<br>
something more comprehensive and tailored to the particular problem<br>
domain you're dealing with, like passlib or cryptography or<br>
itsdangerous.<br>
<br>
Cheers,<br>
Nick.<br>
<br>
P.S. Having the secrets module available on PyPI wouldn't *hurt*, I<br>
just don't think it would help much.<br>
<br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/mertz%40gnosis.cx</a><br>
</blockquote></div>