A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2000-June/004926.html below:

[Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names)

[Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names) [Python-Dev] testing the Python/C API (was: Re: [Patches] PyObject_GetAttr/PyObject_SetAttr core dumps if given non-string names)Guido van Rossum guido@beopen.com
Tue, 27 Jun 2000 16:07:41 -0500
> 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/)



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