Function input decoder

[banteg]

What was wrong?

There was no trivial method to decode function input parameters.

How was it fixed?

This adds Contract.decode_function_input which is a counterpart to Contract.encodeABI.

>>> data = '338b5dea00000000000000000000000042d6622dece394b54999fbd73d108123806f6a180000000000000000000000000000000000000000000000000000000000000032'
>>> contract.decode_function_input(data)
(<Function depositToken(address,uint256)>,
 {'token': '0x42d6622dece394b54999fbd73d108123806f6a18', 'amount': 50})

Works like a charm ✨

Cute Animal Picture

[carver]

Thanks for adding docs and tests right up front!

It's a nice, simple implementation 👍

It's also worth thinking about what should happen during a function selector hash collision.

Most importantly, there are probably some other types worth testing. I added a test example of addresses, which should be returned checksummed, and strings which should be returned as type str.

One approach to solving the address checksum and string tests would be to use map_abi_data() with BASE_RETURN_NORMALIZERS.

I also added the round-trip test (that you can re-generate the transaction data by reusing the method and arguments).

[carver]

This could be a little clearer to newbies that we're talking about the data field of a transaction. Something like:

Decodes the transaction data used to invoke a smart contract function, and returns...

[carver]

The example code could drive the point home with:

>>> transaction = w3.eth.getTransaction(...)
>>> transaction.data
'338b5dea00000000000000000000000042d6622dece394b54999fbd73d108123806f6a180000000000000000000000000000000000000000000000000000000000000032'
>>> contract.decode_function_input(transaction.data)

[carver]

The official docs aren't a good place to advertise a live token (even subtly). :)

Something like ENS (no one profiting) or TheDAO (not live) could be good.

[banteg]

ENS example actually sounds great, I'll update the docs.

[carver]

These expected values would be easier to read if the input arguments were named descriptively, like {'intarg': 1}.

Side note: I am even wondering if we should throw a validation error on an ABI with an empty variable name -- it would probably cause problems elsewhere (not suggesting adding that to this PR).

[carver]

Do you want to add a test against arguments? It's currently unused. Maybe it can just be dropped.

[banteg]

Thanks for pointing out the normalizers feature and adding the tests for additional data types. I updated the code, so now all the tests pass.

I also updated the wording in documentation and replaced the example with the infamous The DAO transaction.

[carver]

Unrelated test failure: occasionally parity integration tests are flaky.

[carver]

Very nice, thanks for the contribution!