After I opened this PR I noticed that I'd made my commit with an old email address. To fix it I rewrote the history on my branch, which I acknowledge is considered poor manners. If that has caused a problem for anyone please let me know and I'll close this PR and open a new one.

Rebasing (rewriting history) of pull requests is expected and welcome.

I have read the guidelines for contributing and tried to follow them.

Unfortunately,. I'm not sure if that's the case, because the guidelines clearly says:

When making your changes, the criteria should be minimizing size of a diff. Change as few lines as possible, within lines, don't change more chars than needed. Prefer commenting out to removal of lines. Don't fix typos, formatting, etc. - if you want them to be fixed, submit patches directly to upstream.

Your patch is too big and appears to change a lot of things for no reason (or unclear reasons). I appreciate that these changes allowed to run it on esp8266, but they're not maintainable for micropython-lib in general.

Thanks @pfalcon, I did run pylint and address some of the formatting findings which are purely cosmetic, these could have been left out. I also removed the dependency on the warnings module, which is a two line module providing a pre-formatted print method in MicroPython, that too is a cosmetic change.

The rest of the changes are generally necessary due to differences between uhashlib and hashlib, such as uhashlib not supporting the copy method which restricts the ability to complete an update after generating a digest or the fact that uhashlib doesn't provide a block_size attribute.

If you were to cherry pick changes, I'd suggest accepting the changes to the translate() method and the test suite. The current HMAC module is broken, in that you may or may not get the correct HMAC generated depending on the key that you use. Including the tests from Python 3.5 allowed me to find the bug and the changes to the translate method fixes it.

Additionally, MicroPython doesn't appear to provide a secure way to compare HMACs. Using '==' to compare secrets is insecure. In cPython the compare_digest method is provided by constant time C code in the _operator module. As far as I am aware MicroPython doesn't expose the same algorithm so I've provided a pure Python implementation that follows current recommended practices to thwart the attacks.

If porting this module to uhashlib introduces more changes than you are comfortable with, I'd like to suggest that we add this module as uhmac so that those working with memory constrained hardware can benefit from a readily available HMAC implementation.

If you were to cherry pick changes

Cherry-picks happen on per-commit level, that's why it's so important to make unrelated changes in separate commits, and do only one, easy to review/test thing in one commit.

Including the tests from Python 3.5

This should be a separate change.

Additionally, MicroPython doesn't appear to provide a secure way to compare HMACs.

Ditto.

I'd like to suggest that we add this module as uhmac

That's how I'd do it, except I'd start uhmac from scratch, to make it truly minimal. Of course, writing security-related code isn't easy, it would take some effort.

So, feel free to split your changes to series of atomic commit (feel free to skip cosmetic changes). Otherwise, someone else will have to do that, and it may take some time.

The block size is 128 bytes for SHA384 and SHA512 and 64 bytes for the others hash function

This problem should be resolved by f95260d