Add deprecation warning to jsonrpc endpoints dropped in EIP 1474

[njgheorghita]

What was wrong?

Add deprecation warnings for jsonrpc endpoints dropped in EIP 1474

Cute Animal Picture

[pipermerriam]

I think the message a user will get is going to be awkward

web3.py/web3/utils/decorators.py

Line 54 in e578dd2

"%s is deprecated in favor of %s" % (to_wrap.__name__, replace_message),

This probably warrants just manually raising the proper deprecation warning exception. Similarly, in v5, we should potentially not fully remove the methods, but make them do a raise DeprecationWarning() which I believe that when raised as an exception is just like normal exception raising. This way people aren't greeted with an AttributeError but a nice explanation of why the method they are accessing is missing.

[njgheorghita]

@pipermerriam 👍 If we're just going to raise DeprecationWarning() in v5 - should I close this PR since the warning is no longer needed in v4? Or should I continue with v4 warnings

[pipermerriam]

So warnings don't break codeflow, they just dump information out so a user who's watching for them knows something is going away. Using the raise syntax breaks code flow so they are two separate mechanisms. These can be easy to mixup since the exception class is called DeprecationWarning but they are to different mechanisms that use the same class.

• warning.warn(...) - for v4
• raise DeprecationWarning - for v5

[kclowes]

Are we switching to the raise DeprecationWarning for all methods we're deprecating in v5? Or just specific ones?

[pipermerriam]

raise DeprecationWarning should only be used if it was previously deprecated meaning that users of v4 would have already been warned.

Otherwise it should use warning.warn(...) to begin giving users a warning

[pipermerriam]

Last thing. Can you add tests for these to show they properly raise the warning with pytest.warns(...).

Same for v5 branch, tests showing the deprecation error gets properly raised. Good to with those changes.