I was in my first months with Python when a crash took me underneath the language.
I wanted VPython on Ubuntu. Under Python 2.6 it segfaulted; under Python 2.5 a known-good package worked. VPython’s 3D core is C++ reached through Boost.Python, so a beginner’s program was failing in the compiled seam between interpreter and library, below any tutorial I knew how to read.
The eventual test plan fits on one line:
interpreter {2.5, 2.6} × architecture {32, 64}
× Boost {released, trunk} × VPython {5.13, 5.11}The first archive thread gave two boundaries. Python 2.5 was known good while 2.6 failed. The 2.6 failure reproduced on both 32- and 64-bit systems, which made word size a poor explanation. The later dependency experiment added another observation: a configuration using Boost 1.40.0rc1 failed, while development trunk identifying itself as 1.41.0 let VPython 5.13 run.
The first successful build changed both Boost and VPython, so I tried VPython 5.11 against the same Boost trunk next. The original tests worked there too, although separate shader and material errors remained. Both VPython versions could run with that Boost build, narrowing the combinations I needed to investigate.
The education below the language
Before I had written much Python, the crash forced me to learn what a binary extension is, why an interpreter version participates in an ABI, what package metadata can and cannot promise, and how to keep a known-good environment as a control. The Python idioms came later. The machinery around Python arrived first because the thing I wanted—spheres moving in a window—sat on its far side.
Keeping the working Python 2.5 setup gave me a comparison while I varied the other pieces. The VPython Years follows what came after; this was where I began looking beneath the Python program itself.