Decoding arbitrary length bytes fails due to expected padding about eth-abi

[fselmo]

@RohitK89, @jad-elmourad

I think I understand what's going on. And this shouldn't be a bug. What the original writers of this library seem to have wanted to keep default is the abi "strict mode". In the Solidity ABI's own examples it is shown that abi.encode() will pad to 32 bytes every time. As an example, the very first example in this section. Notice how everything is neatly formatted to 32-byte lengths.

Decoding, however, is a different thing. Solidity doesn't enforce this "strict mode" by default but the libraries that are built on the python ecosystem do seem to want to keep strict mode as the default so as to keep things a bit more by-the-book. Here's the relevant section.

The Solidity ABI decoder currently does not enforce strict mode, but the encoder always creates data in strict mode."

With the above in mind, I'm hesitant to call this a "bug". But I do think the library should be able to behave as Solidity currently does. I tinkered with this a bit and would need to add more tests but I'm a decent way into being able to provide a flag to decode() that allows you to set strict=False and correctly return the same values Solidity does. At least in the few examples I've tried. I am going to add more robust testing around this but does that sound like a nice compromise?

Thanks for starting the discussion on this 👍🏼

---

edit: @jad-elmourad, if you are open to it, I could push my commits to your PR'd branch and we can collaborate there. Thoughts?

[jad-elmourad]

@fselmo I think adding the optional flag is a great compromise. Please feel free to push your commits there.