bytecode non-backcompatibility

[Terry Reedy]

I think the OP is confusing three different CPython implementation 
features -- bytecodes, marshal format, and C API, all of which change 
pretty slowly -- and a MS Windows/C (dis)feature.

CPython bytecodes only concern code written in Python but are mostly not a 
concern because recompilation is automatic when needed.  The exception is 
code that directly mucks around with bytecodes, especially the intentially 
semi-undocumented numerical codes.

Code objects also include marshaled object values.  The code object for 
'haha = 987654321' must contain representations for the constants 'haha' 
and '987654321' as well as the bytecode for the assignment.  So even if 
bytecodes remain the same, marshal can change (as it did for 2.4, I 
believe, and as it will for floats in 2.5 to fix a bug) and trigger auto 
recompiles.

C extensions interact with the interpreter via function calls that 
constitute the C API.  As much as possible, the developers consciously 
avoid changes that break old code or even old binaries.  Guido has claimed 
that for Linux, there are extension binaries compiled for 2.0 that still 
work with 2.4.

However, for MS Windows/C, there is a 'feature' with respect to DLLs that 
requires recompilation of extensions to work with a new version of the 
Python DLL, even if the C API is unchanged (or so people who understand 
this have said).  So the OPs complaint about having to get and install new 
extension binaries for each Python version might well be directed to MS.

This does not, of course, negate the idea that it would be nice if the 
update process were somehow make easier.  Indeed, the more-batteries 
included distributions from ActiveState and Enthought specifically aim at 
this.

Terry J. Reedy