> 2. Providing a C implementation via the operator module (given the
> restriction to bytes values, and the assumption of caching for all
> relevant integers, would a C reimplementation really be buying us much
> additional security?)

I like the fact that a C implementation can be audited much more easily.
Who knows what kind of effects the Python implementation can trigger, if
some optimizations get added in the future.

> As far as restoring unicode support (even in a C implementation) goes,
> I actually don't like the idea. For the general unicode case, as
> suggested in the updated documentation for hexdigest(), I believe the
> better approach is to try to stay in the bytes domain as much as
> possible, and avoid having a Unicode->bytes conversion for the
> expected value anywhere in the comparison timing path.

The point of supporting unicode would precisely be to avoid a
unicode->bytes conversion when unicode strings are received.