Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA).

Unfortunately we couldn't find an account corresponding to your GitHub username on bugs.python.org (b.p.o) to verify you have signed the CLA. This is necessary for legal reasons before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

Thanks again to your contribution and we look forward to looking at it!

That doesn't seem correct. This will raise an IndentationError: expected an indented block exception.

Also, if you can, please edit the title of the issue to include the b.p.o id by using:

bpo-23984: "title of this issue"

@DimitrisJim You're right, I was hasty while pushing it. Review now

return is not a function, so generally you don't need the ().

However one issue on the issue tracker was "that [the example] gives no hint of why one might want to use a staticmethod". And I don't see how this change improves that. Could you elaborate on that point?

@MSeifert04 I thought about that, and I can explain the usage as well, but the usage can be thoroughly explained a paragraph, would that suffice or should I add a complete OO example(which I think is not required). Correct me if I'm wrong.

I don't think it needs to be a "complete OO example" but just something "better" than returning the argument. Actually staticmethod is rarely used, because Python (unlike Java, ...) doesn't enforce classes-only. So an example should at least hint at possible use-cases in Python. At least that's my interpretation of the comment

FWIW: I'm just a new contributor like you, so please don't assume I know what should be documented there.

@MSeifert04 I think the usage of static method is more theoretical since practically people usually avoid static methods, And the purpose I think is clear from the method, that it can be called via a class or an object of that class. Use cases are just that it might fit into a context of a class which is already specified in the doc.

@DimitrisJim Requesting your input over here.

Using return x looks like the safest option for the time being (mirroring the classmethod example later in the documentation). A little sentence under the example explaining why/where this is useful would probably be needed too.

I'd suggest you stick with return x for now and wait until @rhettinger, the author of this HOWTO, finds some time to come and offer his input on the matter. He'll judge the degree and nature of the change that's required here.

@rhettinger I have made the changes as you proposed. Kindly let me know if you want me to change anything else.

@serhiy-storchaka @rhettinger Is the PR okay to be merged now, please let me know if I can make it better somehow

I removed the " needs backport to 3.6" label, the 3.6 branch no longer accept bugfixes (only security fixes are accepted): https://devguide.python.org/#status-of-python-branches

@brettcannon Hey I had already made changes, I am awaiting review from @rhettinger. He suggested a few changes which I made, only his approval is pending.

I have made the requested changes; please review again

Thanks for making the requested changes!

@serhiy-storchaka, @rhettinger: please review the changes made to this pull request.

Sorry, I can't merge this PR. Reason: Required status check "continuous-integration/appveyor/pr" is expected..

@shubh3794: Status check is done, and it's a success ✅ .

Sorry, I can't merge this PR. Reason: 2 of 4 required status checks are pending..

AppVeyor CI was stuck. I closed/reopened the PR to workaround that.

@shubh3794: Status check is done, and it's a success ✅ .

Thanks @shubh3794 for the PR 🌮🎉.. I'm working now to backport this PR to: 2.7, 3.7.
🐍🍒⛏🤖

GH-12459 is a backport of this pull request to the 3.7 branch.