testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names)
On Mon, Jun 26, 2000 at 01:18:28PM -0400, Jeremy Hylton wrote:
Ok. I was looking for a test case to include in the test suite. I've made the change, but it looks like it will have to go without an accompanying test.
I asked the question a while back if it would reasonable/useful/popular to have a mechanism where parts of the Python/C Api could be tested directly. My proposal used an extension module _testmodule (although I made it a core module on UN*X it should not bog down the core) which exported a bunch o' test_* routines that tested specific parts of the Python/C API. A test_internal.py module would be added to the std regression test suite that would import this module and call each of the exported test_* routines in turn. This would allow things like the _GetAttr/_SetAttr behaviour to be tested. Anybody have any opinions? Trent p.s. I have a patch largely (all except the above menntion limitation) ready for this, including some tests that I used for my 64-bit porting stuff. -- Trent Mick trentm@activestate.com
I think testing the C API directly is a great idea! Sorry I missed it the first time around. I don't think I understand the suggested approach well enough to critique it. Most of the tests need to be written in C, right? When an error is encountered, it seems that you should check what the C API returns *and* what happens at the Python level, i.e. whether the call sets a Python exception (or clears an existing Python exception). I guess you ought to show us the code. I don't think it will go in Python 1.6, but it sounds like a valuable component for future releases. Jeremy
On Tue, Jun 27, 2000 at 01:21:28PM -0400, Jeremy Hylton wrote:
I don't think I understand the suggested approach well enough to critique it. Most of the tests need to be written in C, right? When
All of the testing code would be in C, in the _testmodule.c, or whatever name.
an error is encountered, it seems that you should check what the C API returns *and* what happens at the Python level, i.e. whether the call sets a Python exception (or clears an existing Python exception).
Yes you are right. It depends on the API under test. Basically you just try to test all conditions to ensure that the API behaves as expected/advertised.
I guess you ought to show us the code. I don't think it will go in Python 1.6, but it sounds like a valuable component for future releases.
Okay. I agree that this would probably not make 1.6 so I will probably wait on this for a little while. Busy. Trent -- Trent Mick trentm@activestate.com
trent wrote:
I don't think I understand the suggested approach well enough to critique it. Most of the tests need to be written in C, right? When
All of the testing code would be in C, in the _testmodule.c, or whatever name.
SWIG, anyone? </F>
I asked the question a while back if it would reasonable/useful/popular to have a mechanism where parts of the Python/C Api could be tested directly.
My proposal used an extension module _testmodule (although I made it a core module on UN*X it should not bog down the core) which exported a bunch o' test_* routines that tested specific parts of the Python/C API. A test_internal.py module would be added to the std regression test suite that would import this module and call each of the exported test_* routines in turn. This would allow things like the _GetAttr/_SetAttr behaviour to be tested.
Anybody have any opinions?
Trent
p.s. I have a patch largely (all except the above menntion limitation) ready for this, including some tests that I used for my 64-bit porting stuff.
Great idea. Please wait for 1.7. There *will* be releases after 1.6! --Guido van Rossum (home page: http://www.python.org/~guido/)
[Trent Mick]
I asked the question a while back if it would reasonable/useful/popular to have a mechanism where parts of the Python/C Api could be tested directly.
Not only reasonable, IMO it's essential. "If it's not tested, it's broken." Tattoo that on your neighbor's forehead so it's always in mind <wink>. Every time we get a legit bug report on Python, I view it as a failure of the test suite. That's one of the things I hope to spend a lot of time on (but have not been promised I can spend any time on -- aren't startups great <wink>?).
My proposal used an extension module _testmodule (although I made it a core module on UN*X it should not bog down the core) which exported a bunch o' test_* routines that tested specific parts of the Python/C API. A test_internal.py module would be added to the std regression test suite that would import this module and call each of the exported test_* routines in turn. This would allow things like the _GetAttr/_SetAttr behaviour to be tested.
Anybody have any opinions?
Great start! But the people who most need to take this seriously (including but not limited to me) have no bandwidth to spare before 1.6 is out the door. focus!-it's-not-just-for-breakfast-anymore-ly y'rs - tim
[Trent Mick]
I asked the question a while back if it would reasonable/useful/popular to have a mechanism where parts of the Python/C Api could be tested directly.
Not only reasonable, IMO it's essential. "If it's not tested, it's broken." Tattoo that on your neighbor's forehead so it's always in mind <wink>.
Stay _off_ my forehead, thank you very much. My hairline is receding enough without ink stains killing off hair follicles. Besides, I like my lobster-colored forehead just fine. --da
participants (6)
-
David Ascher -
Fredrik Lundh -
Guido van Rossum -
Jeremy Hylton -
Tim Peters -
Trent Mick