ConciseContract shouldn't be a factory, it should be it's own calling API. meta-tracking in #722
Add deprecation warning to ConciseContract and ImplicitContract. Add a new api: ContractReader.
one proposed api:
contract = w3.eth.contract(address, abi=abi)
reader = contract.reader({'from': caller_addr, ...}) # essentially ConciseContract(contract) with sugar
reader.balanceOf(address) # or whatever call you want to make
Note that there will be internal breakage when removing ConciseContract, notably in the ens module. So part of this change will be updating ENS to use the new reader API. Brief discussion at https://github.com/ethereum/web3.py/pull/1118#discussion_r226800528
Should ContractReader have access to ContractEvents? In my opinion - yes, because events are also part of __reading__ contract data from blockchain.
Hm, I'm not sure we'd be making the events API any easier to call. Maybe name it ContractCaller for semantic alignment?
I like ContractCaller. So the idea is that ContractCaller can only make calls, and removing the ability to use modifiers to make transactions or estimate gas.
For example, this would not be possible:
contract.withdraw(amount, transact={'from': eth.accounts[1], 'gas': 100000, ...})
I was confused by the name ContractReader, which I thought could be an api to read public variables.
for @kclowes
contract.reader.getThing()
Note that's a slight change from the API in the OP: contract.reader(transaction_dict).getThing(). (where transaction_dict has fields like from, gas, gasPrice, etc that can affect the function call.
I think I like the OP API better, but highly open to persuasion or alternatives
@carver I'm inclined to do something like this.
contract.reader.getThing()contract.functions.getThing().call()contract.reader(transaction_dict).getThing()contract.functions.getThing().call(transaction_dict)And maybe to alias contract.r to contract.reader for convenience.
The non-parenthetical API option looks good to me. :+1:
One-letter variables would be super out-of-character for the tool suite.
I think I could get behind it (same for f for functions, etc), but then I would probably want to have a big warning in the docs saying something like "These aliases are intended for 'quick-and-dirty' usage at a terminal, it's highly discouraged to use in production code. Use the full names instead".
... or maybe just not have the alias. Maybe we could shorten reader to read or have it be get instead?
Lets just leave out the alias.
Most helpful comment
I like ContractCaller. So the idea is that ContractCaller can only make calls, and removing the ability to use modifiers to make transactions or estimate gas.
For example, this would not be possible:
I was confused by the name ContractReader, which I thought could be an api to read public variables.