@MikeHathaway can you provide your use case for why you couldn't use contract.events.<your_event_name>.processLog or contract.events.<your event name>.processReceipt?

I encountered the same "problem". I receive a bunch of events from different contracts types at different addresses. I have a means to get the abi of the event from the log, and used to get the processed event with something like:

event = get_event_data(self._get_abi_for_log(raw_event_log), raw_event_log)

Since the way get_event_data works changed for me with upgrading web3, I now have to create a "contract" with only the event abi, which feels like a trick:

event_abi = self._get_abi_for_log(raw_event_log)
# The only public api to process the log is through the `contract` class, so we create one
contract_of_event = self._web3.eth.contract(
    address=raw_event_log["address"], abi=[event_abi]
)
events_of_contract = contract_of_event.events
event_of_log = getattr(events_of_contract, event_abi["name"])()

event = event_of_log.processLog(raw_event_log)

I agree that I could change this in my code by getting the contract and its abi instead of just the event abi upon receiving the log, but it seems unnecessary.

Thanks for the code snippet @cducrest, that helps a lot! I don't see any reason why this wouldn't be able to go in the v6 release. Added to the v6 issue!

We can do this in the v5 line. This isn't a breaking change since it would just be exposing some previously private APIs as public.

doh, true. Thanks @pipermerriam!

@kclowes @pacrob @fselmo this seems like a good fit for eth-utils inside a new contracts.py file. The utilities could be imported as:

from eth_utils import get_event_data, get_function_info

Any other ideas welcome! Let me know if this seems like a good approach.

I'd be more inclined to keep it in web3 and put it in web3/contract/utils.py. It requires more context (an eth-abi codec, the particular subset of the abi for the event, and the entry from a log) than the more generalizable functions from eth-utils normally do.

I don't have context for another use case, though, open to discuss.