Web3.py: Planned v5 changes

[carver]

v5 has no planned release date, but it would be nice to have some ideas in mind for what we would want to change.

Potential v5 backwards-incompatible changes

Each of these line items should have its own issue. This is just a place to link them all (and a reminder to create the issue later).

Edit: I'll try to update this list to keep it in sync with the comments below:

• [x] drop py3.5 support #1163
• [x] rename w3.middleware_stack so it's not called stack #1210
• [x] switch to a single provider instead of a list (maybe) #1200
• [x] rename Web3.sha3 to Web3.keccak #1207
• [x] drop the transact/estimateGas support in ConciseContract, and rename to something like ContractReader - #1227
• [x] ~w3.async things~ shouldn't be API-breaking changes, or delay the v5 release
• [x] only support standard json-rpc methods in the global Web3 namespace, with geth/parity extensions separated into sandboxed namespaces (for example, some personal_* calls are not globally defined or supported and should probably be moved, like personal_importRawKey. Might make sense to have those on something like: w3.geth.personal.importRawKey)
  
  
  
  • [x] #1198
  
  
  • [x] #1211
  
  
• [x] Stop automatically looking up a testnet connection in IPCProvider. #1206
• [x] Stop inferring .eth as a suffix on ENS names. #1205
• [x] remove deprecated methods: #1232
  
  
  
  • [x] removal of contract.call()
  
  
  • [x] removal of contract.transact()
  
  
  • [x] removal of contract.eventFilter()
  
  
  • [x] removal of contract.deploy()
  
  
  • [x] removal of contract.estimateGas()
  
  
  • [x] removal of contract.buildTransaction()
  
  
• [x] drop web3.providers.tester.EthereumTesterProvider and web3.providers.tester.TestRPCProvider #1199
• [x] drop contract.eventFilter #1032
• [x] have web3.eth.getBlock and web3.eth.getTransaction raise an exception rather than return None #1218
• [x] drop web3.utils.* in favor of web3._utils.* - #1282

EDIT: I went through this thread and added all the breaking changes I saw so that they are all in one place. I think once we get through this list and do some testing, we can get a beta release out. - KC

[pipermerriam]

Not sure if you want to list the removals of things that have been deprecated.

• removal of contract.call()
• removal of contract.transact()
• removal of contract.eventFilter()
• removal of contract.deploy()
• removal of contract.estimateGas()
• removal of contract.buildTransaction()

[pipermerriam]

Deprecate Web3.sha3 and rename to Web3.keccak

[carver]

Re: https://github.com/ethereum/vyper/pull/815#discussion_r187383429

After seeing people struggle with it, I do think that we should stop encouraging the use of ContractFactoryClass=ConciseContract in the web3.py docs. But I still think there's value in the concise style. Something like:

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

Many of these features can be added in v4, except it would be nice to drop the transact/estimateGas support in ConciseContract entirely, and drop the name in favor of ContractReader or something.

[pipermerriam]

@carver A pattern we could encourage would be creating your own contract classes combined with some helpers.

from web3.contract import Contract, read_only_fn, read_only_property, contract_fn

class Token(Contract):
    symbol = read_only_property('symbol')
    decimals = read_only_property('decimals')

    balanceOf = read_only_fn('balanceOf')
    myBalance = read_only_property('balanceOf', args=(my_address,))

    transfer = contract_fn(transact={'from': my_address'})

Basically, a guide on how to subclass the Contract class and then some helpers for common patterns like wanting property access to zero argument functions.

[pipermerriam]

I'd love to see web3.async in v5 as well but this list is starting to get long.

[carver]

I'd love to see web3.async in v5 as well

Yeah, we should start exploring it before v5, too. Then, we can figure out what kinds of backwards-incompatible changes might be warranted.

[carver]

Drop some of the repeated endpoints. Use and standardize the "supported endpoints" endpoint. EIP for all current standards.

[voith]

drop web3.providers.tester.EthereumTesterProvider and web3.providers.tester.TestRPCProvider

[dylanjw]

drop contract.eventFilter
deprecation warning for contract.events.<eventname>.createFilter

[dylanjw]

Should we add a warning that v6 will drop support for eth-abi <2?

[pipermerriam]

@dylanjw this issue could probably be broken up into multiple issues and grouped using a milestone. Probably worth us having a v5 milestone so we can start figuring out where we draw the line for a v5 release.

[pipermerriam]

See https://github.com/ethereum/web3.py/issues/1132

I propose that we change web3.eth.getBlock, web3.eth.getTransaction and other similar methods to no longer return None, but instead to raise an exception. The current API encourages/requires return value checking which is not a pattern I think we should be promoting.

[njgheorghita]

• rename w3.middleware_stack so it's not called stack #1210
• drop py3.5 support #1163
• switch to a single provider instead of a list #1199
• rename Web3.sha3 to Web3.keccak #1207
• Stop automatically looking up a testnet connection in IPCProvider.... #1206
• Stop inferring .eth as a suffix on ENS names. #1205
• only support standard json-rpc methods in the global Web3 namespace
• 
  
  • #1198 (merged)
  
  
• 
  
  • WIP - #1211
  
  

[pipermerriam]

I'd like to nominate type hinting to be added to this list, though it isn't a blocker on releasing v5 since it's not a breaking change. I think web3.py is our last major library that isn't type hinted.

[kclowes]

@pipermerriam @carver & @njgheorghita - I _think_ we've completed all of the breaking changes listed in this issue. Do any of you see anything breaking that I missed? We decided that all of the async stuff will be non-breaking, right?

[carver]

Nice! I don't know of a more authoritative list than the one in this issue. So I guess we're ready to go beta! (and time for a blog post :))