Re: Proposal: Reorganizing Python for Python2 (and fixes for the previous proposal)
On 10 Jan 2001 09:16:51 -0600, Rob Tillotson <[EMAIL PROTECTED]> wrote: > Python 1.5 and 2.0 --- there is also jpython, stackless, perhaps > even python.net, and it might eventually be desirable to have all of > these installed side-by-side with separate sets of library modules. Only CPython uses .pycs. Stackless uses the same PYCs as the corresponding version of CPython, JPython uses .class files. Python.NET is MS vapour, so I have no idea what it uses. > Of course, add-ons with .so modules would necessarily be compatible > with only one interpreter Not neccessarily: the API version doesn't change as often as the Python version. -- Moshe Zadka <[EMAIL PROTECTED]> This is a signature anti-virus. Please stop the spread of signature viruses!
Re: Proposal: Reorganizing Python for Python2 (and fixes for the previous proposal)
On 10 Jan 2001 10:07:16 -0600, Rob Tillotson <[EMAIL PROTECTED]> wrote: > > (Does anyone know where the bytecode format is documented? I am > > interested in understanding how bytecode works and is designed.) > > As far as I know it's only documented in the source. The standard > module "dis.py" might be useful to look at as well (it's a bytecode > disassembler). Note that unlike other languages, Python bytecodes are not just strings, they're objects. This means that bytecodes can keep references to other byte codes. .pyc's are actually marshalled code objects (see the Python marshal module). They're not documented on purpose: they change. -- Moshe Zadka <[EMAIL PROTECTED]> This is a signature anti-virus. Please stop the spread of signature viruses!
Re: Proposal: Reorganizing Python for Python2 (and fixes for the previous proposal)
Moshe Zadka <[EMAIL PROTECTED]> writes: > Only CPython uses .pycs. Stackless uses the same PYCs as the > corresponding version of CPython, JPython uses .class files. > Python.NET is MS vapour, so I have no idea what it uses. This isn't really restricted to .pycs -- the point is that a package cannot drop .pycs into a directory and expect all versions of Python to use them. An automatic compilation process could even make .class files for jpython from the same .py source... > > Of course, add-ons with .so modules would necessarily be compatible > > with only one interpreter > > Not neccessarily: the API version doesn't change as often as the > Python version. But for purposes of packaging infrastructure, we can't rely on that. We have to assume that the API might change any time that upstream wants it to, and provide for parallel installation of .so modules if we are going to have parallel installation of Python versions. (This is really more of a build-time issue, I guess -- probably could be handled nicely by a Debian extension to distutils.) --Rob p.s. why the heck does everybody seem to think cc:ing mailing list postings is a good idea? stop, please! I'm on the mailing list, I don't need to see it again... -- Rob Tillotson N9MTB <[EMAIL PROTECTED]>
Re: Proposal: Reorganizing Python for Python 2.0
On Tue, 9 Jan 2001 21:03:57 +0100, [EMAIL PROTECTED] wrote: > From the Python news file: > - Python bytecode files (*.pyc and *.pyo) are not compatible between > releases. Note that this is a promise the Python development team makes : we break the .pyc almost every revision. In particular 2.1 (which should be out in a few weeks) will probably break it too. Better install .pyc only in version specific directories! -- Moshe Zadka <[EMAIL PROTECTED]> This is a signature anti-virus. Please stop the spread of signature viruses!
