If it’s not tested, it’s broken.

오늘 python-dev 메일링에서 –without-pymalloc 옵션을 주면 malloc/free와 관련된 비표준 문제가 생긴다하는 어떤 사람의 질문에 대한 Guido의 답변에 대한 Tim의 답변이 흥미로웠습니다.

[Guido]
I haven't heard of platforms where turning off pymalloc is required --
unless we hear about those, I expect that for 2.4, pymalloc may no
longer be optional.  (The reason: maintaining two versions of the same
code is a pain, and usually the version that's not selected by default
is severely broken after a few releases.)

[Tim]
We never build without WITH_PYMALLOC defined anymore, so under the "if it's
not tested, it's broken" theory, it's already broken &lt;0.5 wink&gt;.  OTOH,
there are really only two substantive WITH_PYMALLOC #ifdefs in the codebase,
and one of them just surrounds the bulk of the code in obmalloc.c.  So as
untested features go, I bet this one is less problematic than
WITHOUT_COMPLEX (which is tested in many more places!).

[Guido]

I haven't heard of platforms where turning off pymalloc is required --

unless we hear about those, I expect that for 2.4, pymalloc may no

longer be optional. (The reason: maintaining two versions of the same

code is a pain, and usually the version that's not selected by default

is severely broken after a few releases.)

[Tim]

We never build without WITH_PYMALLOC defined anymore, so under the "if it's

not tested, it's broken" theory, it's already broken <0.5 wink>. OTOH,

there are really only two substantive WITH_PYMALLOC #ifdefs in the codebase,

and one of them just surrounds the bulk of the code in obmalloc.c. So as

untested features go, I bet this one is less problematic than

WITHOUT_COMPLEX (which is tested in many more places!).

역시 같은 기능에 대해서 두가지 옵션이 안정적으로 제공되려면 덜 매력적인 옵션이 디폴트가 되고 더 멋진 옵션이 선택사항이 되어야, 코드가 깨지는 것을 그런대로 막을 수 있다는 생각이 듭니다. (소비자의 테스터화 작전 -O-;;)

3 thoughts on “If it’s not tested, it’s broken.”