bytecode non-backcompatibility

[Maurice LING]

> The same *can* be said for some decade-old .py files.  Certainly, most 
> everything written for 2.0 onward still works.  The same will also be true 
> for .pyc files as long as you run them with their corresponding binary and 
> as long as the binary stills run.
> 
> However, .pyc files are private, temporary caches created by a CPython 
> interpreter for its own use and tied to its current implementation 
> technology.  They are not intended to be a public distribution form and 
> indeed cannot be a means to run Python programs on other interpreters. 
> Guido has stated that he want the freedom to change or even replace parts 
> of the internal implementation as he sees fit. (2.5 will probably get a new 
> compiler, with the difference mostly transparent to users.)
> 
> One of the principles of OOP is separation of interface from 
> implementation.  User of a class should only use the public interface and 
> not depend on private implementation.  One reason is so implementation can 
> be changed even radically as long as interface is kept constant.  The 
> Python language is interface.  CPython bytecodes are implementation.
> 

 From a technical perspective, I can accept that .pyc files are private 
and temporary. To a certain extend, it does helps development cycle. 
Every time I amend my source codes, I just run it without having to 
consider or needing to re-compile the source files.

The idea of having to release the program or library as source files 
does ring alarms in many executives in corporate world. Less freezing 
the modules (which renders it platform dependent) or using Jython (which 
is not possible when C extensions are involved), there is no middle 
grounds in CPython for distribution without source codes.

Every now and then, there will be new threads in this list about people 
asking the means and possibilities of releasing a module/program without 
having to release the source code (there's another new thread on it 
today, "Can .py be compiled?")...

> 
>>What I do have resources (time and energy) for is to work with the 
>>maintainers of PyPI to implement the package maintenance system I've 
>>described......
> 
> 
> Good.  I agree that we need more along that line.
> 
I've posted my idea on catelog-sig mailing list. Hope it get picked up...

Cheers
Maurice