send_super fixes

[samschott]

This PR fixes #219.

It also aims to provide a uniform API between send_message and send_super. For send_super, argtypes is a keyword argument which defaults to an empty list. This can be convenient if there are no args provided to the call in the first place. I've therefore adapted this for send_message as well. Alternatively, one might make argtypes a mandatory argument for send_super. In any case, I would argue that a uniform API would be nice here.

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[freakboy3742]

Patch looks good; 1 question, and 1 addition request.

The question: The updated version on the setup-python action - is that just a case of using the most recent version, or is there something specific being exercised for which we need the upgrade?

The request: Test cases. We've got a test case for incorrect argument lists for send_message; we should add a similar test set for send_super.

[samschott]

The updated version on the setup-python action - is that just a case of using the most recent version, or is there something specific being exercised for which we need the upgrade?

The smoke test on Python 3.5 was failing because Python 3.5 no longer comes pre-installed on GitHub test runners. setup-python@v2 allows downloading Python versions which are not preinstalled. The alternative would have been to migrate the test to Python 3.6 but I've found that in the past, tests on Python 3.5 have caught some allocation / deallocation related segfaults which appeared to be more flaky in Python > 3.5.

Test cases. We've got a test case for incorrect argument lists for send_message; we should add a similar test set for send_super.

Fair point, will do.

[freakboy3742]

Having access to a broader range of Python versions will definitely be useful. However, Python 3.5 is now officially EOL, so IMHO we don't need to go to excessive lengths to support it. While it may provide utility in surfacing memory allocation errors, using 3.5 won't be a good strategy for the long term, so if we have concerns, we should find some other way (like valgrind) to surface those errors.

[samschott]

I agree, there is no strong case to support it. For now, it just seemed painless to keep testing on Python 3.5 as long as we don't want or need to drop support for any code changes.

[freakboy3742]

👍 Looks good - thanks for the fix!