Home Original page

Near Final PEP 247 - API for Cryptographic Hash Functions

Andrew Kuchling akuchlin at mems-exchange.org
Fri Sep 21 10:35:10 EDT 2001 
On Fri, Sep 21, 2001 at 02:35:06PM +0400, Oleg Broytmann wrote:
>Why not to define __repr__ and __str__?
>
>   __repr__ = hexdigest
>   def str(self):
>      return "%s(%s)" % (self.__class__.__name__, self.hexdigest())

(I assume you accidentally swapped the intended meanings of __str__
and __repr__ in the above.)

Anyway, I don't see the need for defining either one; I'm trying to
keep the interface very minimal.  No one should be parsing the output
of __repr__, so standardizing it doesn't seem necessary.  My
requirement is that the output of __repr__ be helpful when it's
printed during debugging, and that's vague.

Second, why should __str__ be the output of .hexdigest() and not
.digest(), which also returns a string?  Either meaning would be
reasonable, and therefore I don't want to choose either one,
preferring to make people explicitly choose .digest() or .hexdigest().
(I was even doubtful about having .hexdigest() at all -- it could be
removed and people just run the output of .digest() through a hex
encoder -- but was convinced to add it.)

>What about processing files? I think it is very common operation, so why
>not stuff it here?

I wouldn't want to make every module implementor have to rewrite the
same file processing logic, especially since the implementors would
probably be doing it in C.  I'd rather see your suggested function put
in a module of utility functions, so it can be implemented and added
exactly once.

--amk
More information about the Python-list mailing list