Can one run a 1.5 .pyc file with the 2.x version
interpreters and vice versa?
How about running a 2.x .pyc using a 2.y interpreter?
interpreters and vice versa?
How about running a 2.x .pyc using a 2.y interpreter?
-
-
Re: Python bytecode compatibility between interpreter versions
>>>>> "Jon" == Jon Perez <jbperez808@yah oo.com> writes:
Jon> Can one run a 1.5 .pyc file with the 2.x version
Jon> interpreters and vice versa?
Nope, bytecode compatibility is not guaranteed.
--
Ville Vainio http://tinyurl.com/2prnb
-
Re: Python bytecode compatibility between interpreter versions
Jon Perez <jbperez808@yah oo.com> writes:
[color=blue]
> Can one run a 1.5 .pyc file with the 2.x version
> interpreters and vice versa?
>
> How about running a 2.x .pyc using a 2.y interpreter?[/color]
Both are hopeless, in practice.
Cheers,
mwh
--
ZAPHOD: OK, so ten out of ten for style, but minus several million
for good thinking, eh?
-- The Hitch-Hikers Guide to the Galaxy, Episode 2
Comment
-
Re: Python bytecode compatibility between interpreter versions
Jon Perez wrote:
[color=blue]
> Can one run a 1.5 .pyc file with the 2.x version
> interpreters and vice versa?
>
> How about running a 2.x .pyc using a 2.y interpreter?[/color]
What is the specific need you have? There may be ways around
your problem.
-Peter
Comment
-
Re: Python bytecode compatibility between interpreter versions
Peter Hansen wrote:
[color=blue]
> Jon Perez wrote:
>[color=green]
>> Can one run a 1.5 .pyc file with the 2.x version
>> interpreters and vice versa?
>>
>> How about running a 2.x .pyc using a 2.y interpreter?[/color]
>
>
> What is the specific need you have? There may be ways around
> your problem.
>
> -Peter[/color]
I was just curious wrt deployment issues. So I guess it is
fair to say that .pyc files are not as flexible as Java
class files which are at least forward compatible in most
cases (i.e. old class files will run on newer JVMs).
I'm sure a 2.N.x .pyc can run on a 2.N.y interpreter though,
right? :-D
The answers also make me curious about how CPython's VM works.
I suppose that, unlike Java, it is constantly being reworked
in more extensive ways from one dot-version to another. Would
that also explain why there is no detailed spec detailing how
CPython's VM works (since its design is not as nailed down as,
say, the JVM)?
As a programmer, I find installing (and uninstalling) Python
extensions to be about as easy as one can wish for. However,
for end users, it would be great if we can someday have the
equivalent of a Java Runtime Environment with all the important
extensions already included. Then Python developers can distribute
..pycs to end-users and expect them to work with few to no issues.
The things I would like to see in this hypothetical Python Runtime
Environment (PRE) would be Pygame, PyOpenGL, PyGtk (once it finally
matures on Aqua), and the other popular extensions they rely on (like
Numeric - although the current PyOpenGL is experimenting with
using numarray instead).
It may not necessarily have to be the current lightweight distro being
released by the offical Python maintainers, but a separate one
specifically geared for end users who mainly wish to use 3rd party apps
written in Python. Due to Python's nature, such a PRE would also
automatically be an effective developer environment, nullifying the
need for an SDK edition.
Comment
-
Re: Python bytecode compatibility between interpreter versions
> I was just curious wrt deployment issues. So I guess it is[color=blue]
> fair to say that .pyc files are not as flexible as Java
> class files which are at least forward compatible in most
> cases (i.e. old class files will run on newer JVMs).[/color]
It is not about Python being "less flexible" than Java, Python is
evolving. It is also stated in the docs somewhere that bytecode is not
guaranteed to be forwards or backwards compatible.
[color=blue]
> I'm sure a 2.N.x .pyc can run on a 2.N.y interpreter though,
> right? :-D[/color]
Yeah, they try not to do bytecode changes mid point releases.
[color=blue]
> The answers also make me curious about how CPython's VM works.
> I suppose that, unlike Java, it is constantly being reworked
> in more extensive ways from one dot-version to another. Would
> that also explain why there is no detailed spec detailing how
> CPython's VM works (since its design is not as nailed down as,
> say, the JVM)?[/color]
Virtual machine, interpreter, call it what you want. There is probably
documentation somewhere, but the best idea (if you are interested) is to
just take a dive into the source. It is all browsable on sourceforge.
[color=blue]
> As a programmer, I find installing (and uninstalling) Python
> extensions to be about as easy as one can wish for. However,
> for end users, it would be great if we can someday have the
> equivalent of a Java Runtime Environment with all the important
> extensions already included. Then Python developers can distribute
> ..pycs to end-users and expect them to work with few to no issues.[/color]
IMO you are better off packaging them with py2exe or an equivalent for
your platform. Then you can guarantee that your users are running
python version x.y.z, and not x.y.a (minor releases are to fix
relatively important bugs, which may effect the execution of your program).
[color=blue]
> The things I would like to see in this hypothetical Python Runtime
> Environment (PRE) would be Pygame, PyOpenGL, PyGtk (once it finally
> matures on Aqua), and the other popular extensions they rely on (like
> Numeric - although the current PyOpenGL is experimenting with
> using numarray instead).[/color]
Such a PRE would not be small, and trying to get compatible versions of
all of those 3rd party modules, for every supported platform, would be a
pain in the ass.
[color=blue]
> It may not necessarily have to be the current lightweight distro being
> released by the offical Python maintainers, but a separate one
> specifically geared for end users who mainly wish to use 3rd party apps
> written in Python. Due to Python's nature, such a PRE would also
> automatically be an effective developer environment, nullifying the
> need for an SDK edition.[/color]
There already exist 3rd party Python distributions with various add-ons.
I don't know of any off the top of my head (because I have no need for
them), but I have heard mention of them here.
- Josiah
Comment
-
Re: Python bytecode compatibility between interpreter versions
Josiah Carlson wrote:
[color=blue]
> It is not about Python being "less flexible" than Java, Python is
> evolving.[/color]
Note that I specifically mentioned .pyc files vs. java class files,
not Java the language/environment/platform vs. Python.
[color=blue]
> It is also stated in the docs somewhere that bytecode is not
> guaranteed to be forwards or backwards compatible.[/color]
Ah ok.
[color=blue]
> IMO you are better off packaging them with py2exe or an equivalent for
> your platform. Then you can guarantee that your users are running
> python version x.y.z, and not x.y.a (minor releases are to fix
> relatively important bugs, which may effect the execution of your program).[/color]
Right. I am aware that freezing is the optimal way to distribute
apps written in Python today. After trying out Java though, I have
to say I'm impressed with the way you can take a bunch of class
files archived in the exact same jarfile to *ANY* computer with a
JRE installed, type in java -jar jarfile and have it run _identically_.
Perhaps one day .pyc files can work in such a manner.
[color=blue]
> Such a PRE would not be small, and trying to get compatible versions of
> all of those 3rd party modules, for every supported platform, would be a
> pain in the ass.[/color]
That it would not be small I will agree with you on, however I don't
believe version [in]compatibilities will become a PITA as it isn't so
even today.
The whole idea of a Python Runtime Environment came to me precisely
because I have tried out Pygame, PyOpenGL, PyGTK on both Win32 and
Linux and they work seamlessly and uniformly on both platforms (not sure
on OS X though). Note that these are modules that tie intimately with
_different_ low-level APIs on each platform but they work so flawlessly
that it reminds of me of Java's WORA which has been a reality for a
long time now. The main difference is that with Python, getting all
these different modules (for multimedia, 3d acceleration, GUI) installed
involves more steps (though quite easy). Also, because these work
on top of C-based APIs, the performance is significantly superior to
Java's.
[color=blue]
> There already exist 3rd party Python distributions with various add-ons.
> I don't know of any off the top of my head (because I have no need for
> them), but I have heard mention of them here.[/color]
ActiveState's and Pythonware's are the two I am aware of.
Comment
-
Re: Python bytecode compatibility between interpreter versions
| ....
| ActiveState's and Pythonware's are the two I am aware of
There are also the Enthought distributions ....
Python 2.3 and Python 2.2.3
for Windows (Enthought Edition) ....
I've been using the 2.3 version successfully
for several months and chose it specifically
because several add-on packages were included
that I didn't have to seek out and otherwise
individually install ....
--
Cousin Stanley
Human Being
Phoenix, Arizona
Comment
-
Re: Python bytecode compatibility between interpreter versions
"Jon Perez" <jbperez808@yah oo.com> wrote in message
news:c3gqvu$27b ujr$1@ID-180326.news.uni-berlin.de...[color=blue]
> The answers also make me curious about how CPython's VM works.
> I suppose that, unlike Java, it is constantly being reworked
> in more extensive ways from one dot-version to another. Would
> that also explain why there is no detailed spec detailing how
> CPython's VM works (since its design is not as nailed down as,
> say, the JVM)?[/color]
The CPython VM is intentionally underdocumented and intentionally not part
of the language spec. It is still being developed and might radically
change in the future. There will probably be minor changes in the next
release as a result of experiments designed to find combinations of codes
that dependably run faster on all major platforms. However, the current
byte code is described in the Library Ref as part of the doc for the dis
(assembly) module.
Terry J. Reedy
Comment
-
Re: Python bytecode compatibility between interpreter versions
In article <c3hknq$2864jv$ 1@ID-180326.news.uni-berlin.de>,
Jon Perez <jbperez808@yah oo.com> wrote:[color=blue]
>
>Right. I am aware that freezing is the optimal way to distribute
>apps written in Python today. After trying out Java though, I have
>to say I'm impressed with the way you can take a bunch of class
>files archived in the exact same jarfile to *ANY* computer with a
>JRE installed, type in java -jar jarfile and have it run _identically_.[/color]
Really? I'm sorry, I have just a tiny bit of difficulty believing that,
considering all the stories i've heard about Java not being completely
cross-platform and cross-version. I am sure that simple cases work as
you describe, but I'd like a cite for Java working as you describe in
general.
--
Aahz (aahz@pythoncra ft.com) <*> http://www.pythoncraft.com/
"usenet imitates usenet" --Darkhawk
Comment
-
Re: Python bytecode compatibility between interpreter versions
> Right. I am aware that freezing is the optimal way to distribute[color=blue]
> apps written in Python today. After trying out Java though, I have
> to say I'm impressed with the way you can take a bunch of class
> files archived in the exact same jarfile to *ANY* computer with a
> JRE installed, type in java -jar jarfile and have it run _identically_.[/color]
Modulo other dependencies also being installed as well.
You can do the same thing with Python. Just package up the source
files as a zip.
$ PYTHONPATH=exam ple.zip python main.py
You are considering Python .pyc files and Java class files to be
the same thing. They aren't. pyc files are a behind the scenes
implementation detail of one version of the Python interpreter
that are automatically generated and maintained.
Java class files are how you distribute a collection of Java code.
A zip of Python source files is how you distribute Python code
(you can also do it more formally as packages, installers etc).
Roger
Comment
-
Re: Python bytecode compatibility between interpreter versions
In article <c3hknq$2864jv$ 1@ID-180326.news.uni-berlin.de>, Jon Perez wrote:[color=blue]
> Right. I am aware that freezing is the optimal way to distribute
> apps written in Python today. After trying out Java though, I have
> to say I'm impressed with the way you can take a bunch of class
> files archived in the exact same jarfile to *ANY* computer with a
> JRE installed, type in java -jar jarfile and have it run _identically_.[/color]
Spoken like a man who hasn't used much Java.
Joe
Comment
-
Re: Python bytecode compatibility between interpreter versions
On Sat, 20 Mar 2004, Jon Perez wrote:
[color=blue]
> Right. I am aware that freezing is the optimal way to distribute
> apps written in Python today. After trying out Java though, I have
> to say I'm impressed with the way you can take a bunch of class
> files archived in the exact same jarfile to *ANY* computer with a
> JRE installed, type in java -jar jarfile and have it run _identically_.
>
> Perhaps one day .pyc files can work in such a manner.[/color]
Perhaps.
However there is a clear differentiation between Java and Python
in this area:
- Java has always been specified in terms of the language and a
virtual machine design (which implies a portable binary form files for
executables - jar files);
- Python has always been specified in terms of the language, with a
portable reference interpreter implementation for that language (which
just happens to compile to bytecode, and save that bytecode to disk
as an optimisation).
IOW, the bytecode is an implementation detail for _one_ interpreter
implementation.
This becomes obvious when you consider the possibilities associated
with Jython, which could (already does?) compile Python source to jar
files directly.
--
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: andymac@bullsey e.apana.org.au (pref) | Snail: PO Box 370
andymac@pcug.or g.au (alt) | Belconnen ACT 2616
Web: http://www.andymac.org/ | Australia
Comment
-
Re: Python bytecode compatibility between interpreter versions
Aahz wrote:
[color=blue][color=green]
>>Right. I am aware that freezing is the optimal way to distribute
>>apps written in Python today. After trying out Java though, I have
>>to say I'm impressed with the way you can take a bunch of class
>>files archived in the exact same jarfile to *ANY* computer with a
>>JRE installed, type in java -jar jarfile and have it run _identically_.[/color]
>
> Really? I'm sorry, I have just a tiny bit of difficulty believing that,
> considering all the stories i've heard about Java not being completely
> cross-platform and cross-version. I am sure that simple cases work as
> you describe, but I'd like a cite for Java working as you describe in
> general.[/color]
Yes. Java works like that and has for a long time already. One of the
most notable examples i can give is the SVG viewer Batik (not a trivial
program). Worked liked a charm on both Linux and Win32, and it does not
rely on an exact JRE on which it will run on properly. Virtually all
the Swing apps you can try out will work just as reliably and identically
on different platforms as Batik.
The real problem for me is that Java's sound and graphics APIs are not
up to par. Also, the language is clearly not as nice as Python. But
Java _is_ pretty cool and it is a solid (albeit somewhat resource hungry)
piece of technology.
Comment
-
Re: Python bytecode compatibility between interpreter versions
Joe Mason wrote:
[color=blue][color=green]
>>Right. I am aware that freezing is the optimal way to distribute
>>apps written in Python today. After trying out Java though, I have
>>to say I'm impressed with the way you can take a bunch of class
>>files archived in the exact same jarfile to *ANY* computer with a
>>JRE installed, type in java -jar jarfile and have it run _identically_.[/color]
>
> Spoken like a man who hasn't used much Java.
>
> Joe[/color]
If you're speaking from experience, then I'd be interested to
hear exactly what it is you've encountered that leads you to
this view of Java. My experience so far has been contrary to
that.
Automatically assuming that the reason others don't happen to
share your view is due to their lack of experience, just shows
that you are full of conceit.
Comment
Comment