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
--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to