On 2005 Jan 17, at 14:45, Anthony Baxter wrote:
...
>> both, but, of course, everybody's welcome to help!). Surely this
>> can't
>> be the first case in which a bug got triggered only by a certain
>> behavior in an extension type, but I couldn't find precedents. Ideas,
>> suggestions, ...?
>
> Beats me - worst comes to worst, I guess we ship the unittest code
> there with a try/except around the ImportError on the new 'copytest'
> module, and the test skips if it's not built. Then we don't build it by
> default, but if someone wants to build it and check it, they can. I
> don't
> like this much, but I can't think of a better alternative. Shipping a
> new
> extension module just for this unittest seems like a bad idea.
Agreed about this issue not warranting the shipping of a new extension
module -- however, in the patch (to the 2.3 maintenance branch) which I
uploaded (and assigned to you), I followed the effbot's suggestion, and
added the type needed for testing to the already existing "extension
module for testing purposes", namely Modules/_testcapi.c -- I don't
think it can do any harm there, and lets test/test_copy.py do all of
its testing blissfully well. I haven't even made the compilation of
the part of Modules/_testcapi.c which hold the new type conditional
upon anything, because I don't think that having it there
unconditionally can possibly break anything anyway... _testcapi IS only
used for testing, after all...!
Alex
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