Python bytecode compatibility between interpreter versions

[Roger Binns]

> > In general
> > all Java bytecode is expected (but not required) to share the
> > main system JVM.
>
> Afaik, each app will start its own copy of a JVM.

I am not talking about runtime processes, I am talking about installed
files.  The whole point of Java is that you only need one JVM installed
and all apps can use it.  By that I mean one physical copy on the
disk.  Now some apps find that the JVM isn't as version compatible
as they expect and do install a private copy.  But my statement
above still remains true.

> Like I mentioned earlier, I am aware of 'freezing' but having to bundle
> an interpreter with every app is exactly what I would rather avoid...

Why?  Using Windows as an example, the Python interpretter DLL is
974Kb.  The JRE VM is about 1.1MB.  Both Python and Java need a number
of other DLLs, but I believe the Python list is significantly smaller
(a lot more base functionality is built into that Python DLL than is
in the JRE DLL).

> What would be great is to not have to choose between a Windows,
> Mac or Linux or XXX download (like in a proper Java app).

Why?  That then means the user can't use their normal system method
for adding and removing programs and instead have to do things
manually by copying JAR files and potentially other extensions
around.

And here is an example of what really happens in the Java world.
One of the most popular projects written in Java on SourceForge
is Azureus:

http://sf.net/project/showfiles.php?group_id=84122&package_id=88270

Note platform specific installers.  You can also do things manually.
Click on the platform specific Howtos on http://azureus.sf.net/

It does also let you copy the jar file manually, but that then means
you have to manually deal with renames, uninstalls, backups, integrity
checking etc, not to mention having to make your own shortcuts.

> But you're not saying that .pyc files contain profiling information,
> right?  Because that is what it's sounding like...

No.  I am saying they *could* contain it.  They are an implementation
detail of one version of one implementation of a conforming Python
interpretter.  It is free to put *anything* it wants in there including
profiling information and your favourite colour, or just random numbers.

> Yes, this is the main difference between Java and Python.  Python
> prefers the source to be present, Java doesn't care.

Java is a compiled language, just like C/C++ etc.  Python is an interpretted
language without a compilation step.  Some Python implementations
do not require the source to present as they can use the results of
their own earlier tokenization and parsing of Python source.  But that
is implementation specific and not *specified* or *required* anywhere.

> > With the addition of zip imports in Python 2.3,
>
> Correct me if I'm wrong, but I thought you just said earlier that
> zip imports predated Java by several years and now you're saying
> they've just been added to Python 2.3?

No, I said that PYTHONPATH in Python predated CLASSPATH in Java by
several years.  What they can point to has changed in both implementations
over time.

I would recommend you start this thread again, but actually state what
your goals and constraints are, rather than trying to retrofit/force something
(CPython bytecode) as a solution to whatever the unstated problem is.

For the *vast* majority of cases, end users couldn't care less what programming
language or environment is used for any application they get.  They certainly
don't want to have to go around chasing random environments, interpretters,
extensions etc, and manually deal with extra components, upgrades, uninstalls
etc.  They just want to go ahead and use the normal tools for their OS and
be as productive as quickly as possible with the application.

The installer generators solve this problem really well.  In many cases
they even offer some obfuscation of code if used with particular interpretters.
They are also fairly compact.

For example my project includes the code, many images, help files (two diffent
formats), some auxiliary binaries, all required libraries and the Python interpretter
etc in 5MB.  Azureus ships as a 3.2MB installer, but that excludes the JRE
which is a seperate 15MB download.

Note that the full Python environment (which is way closer to the JDK and even
includes an IDE, debugger etc) is a 9.3MB download.

In the Java world, there are two issues that result in a certain way of thinking.
One is that you know your code is supposed to run on any JVM.  The second
is that the JVM is a large download.  Consequently this leads to the mindset
of trying to use one installed JVM for all apps, and doing some manual
configuration to get things working.

Python isn't Java, and doesn't have this mindset.  The Python mindset is
to make things as easy and logical as possible, especially without users
(or developers!) having to be aware of implementation details.

Roger