Contract extensions API

[pipermerriam]

What was wrong?

The py-ethpm library currently has to use a subclass of the Contract class to achieve some of the desired functionality (LinkableContract).

This approach isn't friendly towards any other code which also needs to extend the contract class in some way.

How can it be fixed?

Currently using the name "Contract Extensions".

A contract extension would be a class. Probably inheriting from a standard base class that does some internal plumbing that the user doesn't need to be concerned with.

from web3.contract import BaseContractExtensions

class EthPMExtension(BaseContractExtension):
    def do_thing(self):
        ...

The idea is to get things wired up such that self in the method above is the contract instance. We can do this with some which craft/sorcery/dark-magic.

Then maybe use them like this:

MyContract = w3.eth.contract(..., extensions={'ethpm': EthPMExtension})

Then from the contract instance:

my_contract.ext.ethpm.do_thing()

In theory we can also expose an API for registering extensions that go on all contracts by default, or maybe event dynamically adding them at runtime after contract class/instance creation.

Taking this idea further could be doing thing likes:

• lifecycle hooks like before_deploy/after_deploy
• middleware type functionality to muddle with the JSON-RPC requests.

[pipermerriam]

@kclowes I just realized that this might end up being part of your async support work. We could probably model the functions and events APIs on the contract as extensions, which would naturally allow us to swap out the sync implementation for an async implementation of the Contract.events and Contract.functions APIs. In theory we could model the majority of the contract APIs using this extensions concept.

[pacrob]

ethPM will be deprecated in v7, closing as wontfix.