Constructing expected_opinfo_* lists in test_dis.py
I'm still messing around with my register VM stuff (off-and-on). I'm trying to adjust to some changes made a while ago, particularly (but probably not exclusively) after RERAISE acquired an argument. As a result, at least the expected_opinfo_jumpy list changed in a substantial way. I can manually work my way through it, but it sorta seems like someone might have used a script to translate the output of dis.dis(jumpy) into this list. Am I mistaken about this? Thx, Skip
Maybe these lines in test_dis.py? ``` #print('expected_opinfo_jumpy = [\n ', #',\n '.join(map(str, _instructions)), ',\n]', sep='') ``` On Sun, Jan 31, 2021 at 6:07 PM Skip Montanaro <skip.montanaro@gmail.com> wrote:
I'm still messing around with my register VM stuff (off-and-on). I'm trying to adjust to some changes made a while ago, particularly (but probably not exclusively) after RERAISE acquired an argument. As a result, at least the expected_opinfo_jumpy list changed in a substantial way. I can manually work my way through it, but it sorta seems like someone might have used a script to translate the output of dis.dis(jumpy) into this list. Am I mistaken about this?
Thx,
Skip _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/M6UGHHF4... Code of Conduct: http://python.org/psf/codeofconduct/
-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
Guido> Maybe these lines in test_dis.py? ... Skip> Thanks, I'll take a look. I was expecting there'd be a standalone Skip> script somewhere. Hadn't considered that comments would be hiding Skip> code. Indeed, that did the trick, however... I'm a bit uncomfortable with the methodology. It seems test_dis is using the same method (dis.get_instructions) to both generate the expected output and verify that dis.get_instructions works as expected. For the most part, you see the test case fails, rerun the code to generate the list, substitute, et voila! The test (magically) passes. Somewhere along the way, it seems there should be a way to alert the user that perhaps dis.get_instructions is broken and its output is not to be trusted completely. Skip
Hi Skip, On 01/02/2021 9:50 pm, Skip Montanaro wrote:
Guido> Maybe these lines in test_dis.py? ... Skip> Thanks, I'll take a look. I was expecting there'd be a standalone Skip> script somewhere. Hadn't considered that comments would be hiding Skip> code.
Indeed, that did the trick, however... I'm a bit uncomfortable with the methodology. It seems test_dis is using the same method (dis.get_instructions) to both generate the expected output and verify that dis.get_instructions works as expected. For the most part, you see the test case fails, rerun the code to generate the list, substitute, et voila! The test (magically) passes. Somewhere along the way, it seems there should be a way to alert the user that perhaps dis.get_instructions is broken and its output is not to be trusted completely.
The problem is not that dis.get_instructions can't be trusted, but that the test isn't testing the dis module at all. It is testing whether the output from the compiler has changed. A lot of the tests in test_dis do that. Cheers, Mark.
Skip _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FAI7XYMY... Code of Conduct: http://python.org/psf/codeofconduct/
The problem is not that dis.get_instructions can't be trusted, but that the test isn't testing the dis module at all. It is testing whether the output from the compiler has changed. A lot of the tests in test_dis do that.
Thanks. Perhaps such tests belong in a different test_* module? (I ask this in a rhetorical sense.) I realize that there can not be (nor should be) perfect isolation of test cases so that (for example) test_sys.py includes all tests of sys module functionality. Still, if a fairly large chunk of the contents of test_dis.py don't test dis module functionality (I'm guessing >= 50%), perhaps moving them to test_compiler.py or something similar would be a stronger signal about their intent. Skip
participants (3)
-
Guido van Rossum -
Mark Shannon -
Skip Montanaro