Less harsh implementation for issubclass()

[raamana]

Apologies if this does not fully conform to the contrib guidelines (please close it if so), but I think this is a trivial change, and likely does not need any discussion on bugs.python.org.

When trying to write tests for one of my libraries, I wanted to ensure a certain input param is a proper subclass, and to ensure it fails for invalid input, I ran tests with not-class inputs like a string etc. This has been discussed in #5944 and #6188, where the decision was raise an error requiring a class-type input. I think this could be made less harsh by simply returning False, while issuing a warning.

I'm not a cpython expert and not sure warnings module is available in that environment, I put it in there to give an idea of the ideal behaviour of issubclass I'd expect. Apologies if this does not fully conform to the contrib guidelines -please close it if so. Thank you for the consideration.

[the-knights-who-say-ni]

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 might be simply due to a missing "GitHub Name" entry in your b.p.o account settings). 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.

You can check yourself to see if the CLA has been received.

Thanks again for your contribution, we look forward to reviewing it!

[tirkarthi]

This could result in confusion where it's not actually a subclass returning False and also an invalid call returning False. Warnings may not be visible in all environments and configurations and probably ignored. It's better to have an error and if you want to ignore the error then you can catch the TypeError and silence as needed. This would require a discussion in https://bugs.python.org or python-dev mailing list since this is a backwards incompatible change if you would like to proceed further.

Thanks

[raamana]

The confusion isn’t harmful and does not lead to any incorrect result as any input that’s not a class also is not actually a subclass of the second arg. Throwing an error here or adding try/catch code downstream is unnecessarily harsh.

I understand the backwards incompatibility issue, but perhaps have a deprecation cycle? Please go ahead pass it along to bugs.python.org. Happy to help in minor ways, I won’t be able to lead the debate or dev.

[jdemeyer]

does not need any discussion on bugs.python.org.

It's a functional change, it certainly needs an issue.

[matrixise]

Hi all and @raamana

Thank you for your contribution but I am going to close this PR, the CLA is not signed by @raamana. @raamana once you will have signed the CLA and this one will be in https://bugs.python.org you are free to re-open your PR and we will process it.

Also, because there is a change in the algo, as @jdemeyer as suggested, I propose to you to open an issue in BPO (bugs.python.org) and discuss that issue.

Thank you so much,