Hi Steven, No probIem with the delay -- it's still before 3.6.0. I do think it's just about a record gap in the PEP review process. :-) I will approve the PEP as soon as you've updated the two function names in the PEP. (If you don't have write access to the peps repo, send the new version to peps@python.org -- or send a link to the new draft somewhere online, e.g. github if you're using that. If you do have peps repo write access, just reply here when it's done.) Regarding the alluded vagueness of the PEP on the specs, I think I was mostly about the phrase "At the time of writing, the following functions have been suggested" which doesn't seem to commit very strongly to a specific API. The later phrase "The following pseudo-code can be taken as a possible starting point for the real implementation" doesn't really do much to take away the feeling that the PEP is non-committal on the actual API it proposes. But I don't want to approve the *idea* of a secrets module -- I want to approve a specific API. Maybe you can just change the words a bit to say something like "this PEP proposes the following API; the implementations given here are not final". None of this will prevent adding more functions to secrets.py before 3.6.0 is released (or, of course, in 3.7, 3.8 etc.), but it should send a clear message that we've agreed on these specific names and signatures, and that those are what I'm approving. If we change our minds about the API of the module before releasing 3.6.0, we should treat it as an amendment to the PEP and take it pretty seriously (but it's happened before so it's not impossible). Hopefully this message isn't drowned in the infinity of pathlib and ~bool threads, and we can proceed to add secrets.py to the 3.6 stdlib. You should be proud of that accomplishment! --Guido On Sat, Apr 9, 2016 at 10:08 PM, Steven D'Aprano <steve@pearwood.info> wrote:
I've just spotted this email from Guido, sorry about the delay in responding.
Further comments below.
On Thu, Jan 14, 2016 at 10:47:09AM -0800, Guido van Rossum wrote:
I think the discussion petered out and nobody asked me to approve it yet (or I lost track of it). I'm almost happy to approve it in the current state. My only quibble is with some naming -- I'm not sure that a super-generic name like 'equal' is better than the original ('compare_digest'),
Changed.
and I would have picked a different name for token_url -- probably token_urlsafe. But maybe Steven can convince me that the names currently in the PEP are better.
Changed.
(I also don't like the wishy-washy position of the PEP on the actual specs of the proposed functions. But I'm fine with the actual implementation shown as the spec.)
I'm not really sure what you want me to do to improve that. Can you be more concrete about what you would like the PEP to say?
I haven't updated the PEP yet, but the newest version of the secrets module with the changes requested is here:
https://bitbucket.org/sdaprano/secrets
-- Steve _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido)