[Python-checkins] CVS: python/nondist/peps pep-0247.txt,NONE,1.1

[Moshe Zadka]

Cool!

On Tue, 27 Mar 2001, "A.M. Kuchling" <akuchling@users.sourceforge.net> wrote:

>    new([string], [key])

What happens if I supply a key to an unkeyed hash?
Is it silently ignored?

>    clear()
> 
>       (XXX what should this do for a keyed hash?  

Your solution seems fine.

>    digest()
> 
>       Return the hash value of this hashing object, as a string
>       containing 8-bit data. The object is not altered in any way by
>       this function;

Why this constrain? I can imagine algorithms for which this will create
an artificial inefficiency. It's not such a common need, and if someone
really needs it, she can just take hash.copy().digest()

Also, the PEP needs to spell out the existence of a Crypto.Hash package
more clearly, and I think even an API for a factory function would be
very useful.

>>> import Crypto.Hash
>>> md5 = Crypto.Hash.factory('md5')
>>> md5.update("dddd")
>>> print >>open("file", 'w'), binascii.hexlify(md5.digest())

Oh, and I think that Mixed Case Is Evil(tm), and that crypto.hash
would be just fine. But I don't care really.
-- 
"I'll be ex-DPL soon anyway so I'm        |LUKE: Is Perl better than Python?
looking for someplace else to grab power."|YODA: No...no... no. Quicker,
   -- Wichert Akkerman (on debian-private)|      easier, more seductive.
For public key, finger moshez@debian.org  |http://www.{python,debian,gnu}.org