I say "mostly" because, while the bytecode is cross-platform, it is
version dependent.  A Python 3.x installation may or may not be able
to run a bytecode compiled by Python 3.y.

Note though that when a .py file is executed directly (not imported),
it does not look for or generate a .pyc file; it just compiles the .py
unconditionally in memory and runs the bytecode.

If you're interested in the bytecode, you can use the dis module to
disassemble functions and other code objects and examine it:

java has available a "runtime" environment, for those who don't want or
need the compiler.  CPython comes with the compiler and the runtime
bundled together.

Java's classfile remains stable over a number of compiler versions,
while CPython doesn't seem to worry about that.

Java's classfile has been targeted by a number of other byte code
compilers, including jython.  Code from any of those libraries may use
the java libraries.

With java, one has to explicitly compile the java code, while with
CPython, the runtime logic compiles imported modules if they're not
already compiled.

--

Java's bytecode and source code are two distinct languages, both well
documented and separately usable (and with their own distinct
limitations - there are things you can do in Java bytecode that you
cannot do in Java source). With CPython, the bytecode is an
implementation detail and an optimization (once it's parsed your .py
file once, a .pyc file can be saved to allow the interpreter to save
some effort next time).

The model for programming languages used to be:

Interpreters go over the source code, line by line, executing each line
as it is read. If you loop over a line twice, it gets read twice,
interpreted twice, and executed twice.

Compilers go over the source code once, line by line, interpreting the
code once, building machine code which can be directly executed by the
hardware.

Even back in the 1970s this simple picture was not quite right: it hides
a lot of detail. Many "compiled" languages would compile to assembly
language for a virtual machine, rather than direct to hardware specific
machine code. For example, some Pascal compilers would compile code for a
virtual p-machine. Languages like Forth can switch from "compile" mode to
"interpret" mode from one command to the next. And of course, machine
code itself is interpreted by the hardware, and there are many ways of
setting up the machine code (e.g. direct vs indirect threaded code) which
may be faster or slower at the expense of more or less memory. So the
distinction between compiled and interpreted has always been a bit fuzzy.

These days it is a lot fuzzy. Any "compiled" language that includes an
eval or exec function must include an interpreter; nearly all
interpreters compile code to byte code, and the few that don't usually
build a parse tree instead.

And then there are Just In Time compilers, which compile to machine code
instructions at runtime, giving the flexibility of interpreters with the
speed of compilers. An interpreter with a clever enough JIT can be faster
than a static compiler, which leads to cases where Python can be faster
than C:

http://morepypy.blogspot.com.au/2011/02/pypy-faster-than-c-on-careful...

http://morepypy.blogspot.com.au/2011/08/pypy-is-faster-than-c-again-s...

This basically means that as a program is executing, the JVM will
sometimes go through what is a more traditional compilation step and
translate its bytecode into machine code rather than just interpret it.
It will do this for things it discovers are "hot paths" through the
program, where spending some extra time up front (while the program is
still executing!) for the compilation and optimization steps is worth it
in terms of the speedup. In fact, the JVM may transform a given piece of
bytecode several times, applying new optimizations as it discovers that
some block is not just important, but *really* important. :-) (Where
"important" = "executed a lot.")

By my understanding, CPython doesn't do any of this; it always executes
the same byte code in the same way, and what it does to the bytecode
looks more like an interpreter than a JIT compiler. On the other hand,
Jython translates Python to Java bytecode and IronPython translates
Python to .Net bytecode (MSIL), so if you use one of those
implementations of Python, you are getting a JIT. (Nevertheless my
understanding is both tend to be slower than CPython? Not sure about
that, and don't know by how much or why.) The new kid on the block is
PyPy, which is a JIT engine for Python written in Python itself.

But the interesting point is that the (very) old view of "compiled or
interpreted" breaks down a lot nowadays; it's closer to a continuum:

 - pure interpreted
 - compiled to bytecode, which is then interpreted
 - JIT compiler (almost always this has a bytecode compilation step
   though theoretically this isn't necessary)
 - pure compiled

I'd say these categories tend to be qualitative "I know it when I see
it" rather than hard divisions.

Evan