[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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4