bytecode non-backcompatibility

[Steve Holden]

Maurice LING wrote:
> 
>> All you have to do is convince the developers to declare the set of
>> bytecodes fixed, and they'd be stable. I don't think that will be
>> easy, as it removes one of the methods used to improve the performance
>> of Python. Since rebuilding the bytecode files is trivial (just invoke
>> compileall.py in the library as a script), this isn't really a
>> problem. The only thing that breaks are modules that muck about inside
>> the bytecode. I don't know how much bytecode improvements have sped
>> things up, but I do know that if I ever used a module that mucked
>> around with byte codes, I wasn't aware of it - so this is a tradeoff
>> I'm more than happy to make.
>>
> 
> Thanks Mike,
> 
[... arguments about bytecode stability ...]
> 
> What other point are there?
> 
> I may be chopped by saying this but by having a stable set of bytecodes, 
> we may lose a means of optimization. But we may gain more from filling 
> the need for commerical distribution of applications writing in Python 
> and ease of upgrading...
> 
> At current stage, every time a new version of Python is installed in my 
> server or system, I have to test and ensure the needed libraries are 
> there... which may be a horror in corporate settings. Couple that with 
> messy dependencies of the libraries to be installed. I remembered the 
> time I was trying to install Eric 3, the dependencies makes me want to 
> give up... I have to install Qt, then pyQt, then something else, then 
> Eric3. Imagine you need 10 of those libraries... which may happen... I 
> am not yet masochistic enough to take pleasures in this...
> 
> I also hope some python developers are reading this thread as well...... 
>  Call this a desperate plea from some of us......
> 
> Cheers
> Maurice

There's enough attention to backward compatibility that the chance of 
code breakage is quite small for pure-Python modules. Given that case, 
all we really need for them is a suitable way of moving them forward to 
an updated distribution (though, of course, the module authors may have 
brought out new versions that use more advanced language features, there 
is no real compulsion to migrate to those if you seek stability).

I don't believe that the major problem is the changes to the bytecodes - 
extension modules (those written in C and/or C++) don't generally use 
the bytecodes anyway. The real problem is the API to the interpreter, 
which again the developers retain the right to change between minor (but 
not micro) versions.

regards
  Steve
-- 
Steve Holden        +1 703 861 4237  +1 800 494 3119
Holden Web LLC             http://www.holdenweb.com/
Python Web Programming  http://pydish.holdenweb.com/