<br><div class="gmail_quote">On Tue, Jun 12, 2012 at 2:34 PM, Antoine Pitrou <span dir="ltr"><<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On Sun, 10 Jun 2012 10:56:46 -0700<br>
"Gregory P. Smith" <<a href="mailto:greg@krypto.org">greg@krypto.org</a>> wrote:<br>
> I'd just stick it in hmac myself but getpass was also a good suggestion.<br>
>  Cross reference to it from the docs of all three as the real goal of<br>
> adding pbkdf2 is to advertise it to users so that they might use it rather<br>
> than something more naive.<br>
><br>
> hashlib itself should be kept pure as is for standard low level hash<br>
> algorithms.  It can't have a dependency on anything else.<br>
<br>
</div>I don't really understand this requirement. Can you elaborate?<br></blockquote><div><br></div><div>I wrote that quickly.  I don't want a circular dependency or things that aren't well established standards in hashlib.  I see hashlib as being for low level algorithms only (FIPS standards, etc) where fast implementations are available in most VM runtimes.  hmac depends on hashlib therefore nothing in hashlib should ever depend on hmac.  That doesn't prevent someone from deciding hmac shouldn't be a module of its own and moving it to live within hashlib some day but that would seem like needless API churn outside of a major language version change.</div>

<div><br></div><div>-gps</div></div>