Home www.python.org
Download Documentation
Documentation
Overview
Executive Summary
Invoking JPython
JPython Registry
Embedding
Compiling JPython from source
 
Working with Java
The Basics
JavaBean Properties
Java arrays
Subclassing
Building applets, servlets, beans...
 
Python Docs (exits)
Python Tutorial
Library Reference
 
Other
JPython vs. CPython
JPython FAQ
List Archives (exit)
JPython paper (exit)
 
Email Us
jpython@python.org
 
  

Differences between CPython and JPython

CPython and JPython are two different implementations of the Python language. While a Language Reference exists for the Python language, there are a number of features of the language that are incompletely specified. The following lists all known differences between the two implementations of the Python language. These differences range from the trivial -- JPython prints "1.0E20" where CPython prints "1e+020" -- to the dramatic -- everything in JPython is an instance of a class. At some point more effort should be made to separate the interesting differences from the mundane.

Any other differences not listed here can probably be considered a bug in JPython. Understand of course that CPython and JPython advance at different paces. All efforts are made to keep the two implementations in sync, but that's not always possible.

This list has been updated to describe the differences between JPython 1.1beta4 and CPython 1.5.2

Syntax

  • JPython has a different interpretation of floating point literals. CPython doesn't allow 001.1 CPython should be fixed.

  • JPython supports continue in a try clause. CPython should be fixed - but don't hold your breath.

Standard types, functions and behavior

  • JPython string objects support full two-byte Unicode characters and the functions in the string module are Unicode-aware. CPython should add Unicode support in the future, though the details of this are still unclear.

  • JPython string objects have methods, providing a more convenient interface to most of the string module functionality. This feature has been added to CPython and will appear in version CPython 1.6.

  • JPython formats floating point numbers differently, e.g. an upper case 'E' is used, and it switches over to E notation sooner than CPython does. Both behaviors are acceptable.

  • In JPython, 0.1**4 is printed as 1.0000000000000002E-4. In CPython, it is printed 0.0001, even though it is not actually equal to 0.0001. Both behaviors are acceptable for now -- this is still being discussed.

  • JPython sequences support three argument slices. i.e. range(3)[::-1] == [2,1,0]. CPython should be fixed.

  • Every object in JPython is an instance of a class -- there are no types in JPython. i.e. [].__class__ is a sensible thing to write in JPython. CPython should be fixed - but don't hold your breath.

  • The .tell() method on JPython file objects returns a Python long, while the .tell() method on CPython file objects returns a Python int. Whether or not both behaviors are acceptable is still unclear.

  • JPython file objects are still missing some functionality -- see todo list in PyFile.java. (Hopefully in the near future this can be changed to read -- JPython file objects include the following extra functionality to properly handle non-ascii files...) JPython should be fixed.

  • In CPython, range(0.1, 3.2) yields the surprising [0, 1, 2]. JPython does the right thing (reject float arguments). -- Many other functions taking int arguments have the same problem. CPython should be fixed.

  • In CPython, the list.append() method takes multiple arguments and forms a tuple. JPython's append() method requires one argument only. CPython should be fixed -- but probably won't be due to backwards compatibility.

  • The __name__ attribute of built-in extension modules (e.g. 'sys') is different. Both behaviors are acceptable.

  • In many cases, introspection yields different results. Where appropriate and possible, JPython will adhere to CPython's introspection behavior. Some differences are acceptable.

  • JPython defines __debug__, but always sets it equal to 1. JPython should implement CPython's -O option.

  • The locals() dictionary in JPython is mutable from within a function. After "def foo(x=1): locals()['x'] = 2; print x" foo() prints 1 in CPython and 2 in JPython. Jim thinks that JPython's behavior is better here -- but the best answer might be that locals() should be considered a read-only dictionary. Proper behavior here is still unclear.

  • JPython doesn't support restricted execution mode and doesn't have the magic __builtins__ in every namespace. JPython will probably never support restricted execution mode -- Java's security model is recommended instead.

  • JPython uses different values for the IOError argument. This causes trouble for people who unpack the value into an (errno, message) tuple. Both behaviors are acceptable.

  • JPython code objects are missing other attributes -- co_code, co_consts, co_lnotab, co_names, co_nlocals, co_stacksize. co_flags is now supported because the Python debugger requires it. Other attributes will probably never be supported in JPython due to its implementation of code objects as compiled Java bytecodes.

  • Accessing, setting, or deleting attributes on built-in objects may raise AttributeError or TypeError differently. This is considered implementation dependent. In JPython the following rules are used: when getting a non-existant attribute, AttributeError is raised; when setting or deleting a readonly attribute, TypeError is raised; when setting or deleting a non-existant attribute, AttributeError is raised. Be aware though currently neither JPython nor CPython are completely consistent.

  • Function objects do not have writable func_code or func_defaults attributes. While these are writable in CPython, I haven't decided whether they should be writable in JPython.

  • JPython has "true" garbage collection whereas CPython uses reference counting. This means that in JPython users don't need to worry about handling circular references as these are guaranteed to be collected properly.  On the other hand, users of JPython have no guarantees of when an object will be finalized -- this can cause problems for people who use open("foo", 'r').read() excessively. Both behaviors are acceptable -- and highly unlikely to change.

  • In JPython, __del__() methods in user-defined classes are never called. Some future version of JPython might provide limited support for __del__(), but see the above item.

  • The dictionaries used by classes, instances, and modules in JPython are not the same as the dictionaries created by {}. They are StringMap's which require all of their keys to be strings. After "class c: pass", c.__dict__[1] = 2 will work in CPython, but will raise a "TypeError: keys in namespace must be strings" error in JPython. Both behaviors are acceptable -- CPython might adopt JPython's approach in the future for the performance gains it can provide.

Extension modules

  • JPython supports all Java packages as extension modules. i.e. from "java.lang import System" will work in any JPython implementation. This functionality might be added as an optional extension to some future version of CPython.

  • JPython includes the builtin module jarray -- which allows Python programmers to create and manipulate Java array objects.

  • Lots of builtin extension modules don't exist in JPython.
    • Modules struct, cPickle, cStringIO, and operator were all added for JPython v1.1. The following are likely to be implemented in a future version of JPython -- cmath.

    • The following are under consideration (working code would make the decision much easier ;-) -- array, select, a dbm/gdbm/bsddb style module, Numeric.

    • The following are highly unlikely any time soon -- Tkinter. However, Finn Bock has a JNI implementation called jTkinter which supports the full _tkinter API. Very cool stuff!

    • Let me know if something should be added to this list.

  • __builtin__ module

    • Incomplete implementation of __import__ -- only one argument is allowed and replacing this with a user-defined function has no effect. JPython might be fixed in a future release, but CPython will probably adopt a new import mechanism in the near future, so JPython may not change until the new mechanism is defined.

  • os module
    • popen() and system() are missing. JPython should be fixed, patches would be graciously accepted.

    • os.path.normcase() exists but may not be correctly implemented. This one is extremely frustrating as there seems no portable way to implement in Java.

    • chmod(), chown(), getpid(), fork(), ... are missing, stat() exists but is implemented incompletely. These functions are all very Unix specific and it is unlikely they will ever be properly supported in a 100% Pure Java implementation.

      Finn Bock has created a JNI/C++ implementation for the posix module. See Finn Bock's JPython modules page for details. Note that his cPickle, cStringIO, binascii, and struct modules have all been integrated into JPython 1.1.

  • The socket module is limited.

  • sys module

    • JPython is still missing exitfunc

    • Also missing executable, getrefcount, setcheckinterval which don't make much sense for JPython.

  • thread module

    • CPython's thread modules defines some aliases that JPython's doesn't. These aliases are considered obsolete and won't be supported by JPython.

  • Harry Mantakos has contributed the underlying md5 implementation, so now the md5 module works out of the box.

  • The time module may produce some different values than with CPython. This is due to Java 1.1 compatibility, and this may be improved in later releases.

Interpreter and environment

  • JPython doesn't catch interrupts. Only fixable with a GUI console since interrupts are not supported by Java.

  • JPython doesn't have command line editing. Only fixable with a GUI console. However, Un*x users can check out rlterm which provides generic GNU Readline support for any terminal based interactive program. rlterm is part of the Yorick package.

  • JPython should have a feature similar to $PYTHONSTARTUP, which specifies a script to run at the start of interactive mode only.

  • JPython supports different command line options than CPython, e.g. "-jar" and "-D". It also has a different convention for indicating non-interactive standard input (the Java runtime needs help).