jython / Doc /

Title: Differences between CPython and Jython

<h3>Differences between CPython and Jython</h3>

<P>CPython and Jython are two different implementations of the Python
language. While a <A HREF="">Language
Reference</A> 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 --
Jython prints &quot;1.0E20&quot; where CPython prints
&quot;1e+020&quot; -- to the dramatic -- everything in Jython is an
instance of a class.  At some point more effort should be made to
separate the interesting differences from the mundane.

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

<p><i>This list
has been updated to describe the differences between Jython-2.0 and
CPython 2.0</i>


    <LI>Jython has a different interpretation of floating point
    literals. CPython doesn't allow 001.1 <I>CPython should be

    <p><LI>Jython supports continue in a try clause. <I>CPython
    should be fixed - but don't hold your breath.</I>

    <p><LI>Jython allows keywords to be used as identifier name
    in some situations where there are no conflict. This allows
    jython to call and override java methods with names like 'print'
    and 'exec'. <I>Both behaviors are acceptable.</I>

<h3>Standard types, functions and behavior</h3>

    <LI>Jython have only one string type which support full 
    two-byte Unicode  characters and the functions in the string
    module are Unicode-aware. The u"" string modifier is optional
    and completely ignored if specified.
    CPython-2.0 have two string types, the classic 8-bit string and 
    and new unicode string which is created with the u"" string modifier.
    <I>Both behaviors are acceptable.</I>

    <p><li>Jython uses the character properties (isuppercase, isdecimal, ...)
    from the java platform. Java uses Unicode-2.0 and not all unicode properties
    is available through java.
    CPython-2.0 uses Unicode-3.0 and all unicode properties are available. 
    About 340 of the unicode points have different properties.
    <I>Both behaviors are acceptable.</I>
    <p><LI>Jython formats floating point numbers differently,
    e.g. an upper case 'E' is used, and it switches over to E
    notation sooner than CPython does. <I>Both behaviors are

    <p><LI>In Jython, 0.1**4 is printed as
    1.0000000000000002E-4. In CPython, it is printed 
    <I>Both behaviors are acceptable.</I>

    <p><LI>Jython sequences support three argument
    slices. i.e. range(3)[::-1] == [2,1,0]. 
    <I>CPython should be fixed.</I>

    <p><LI>Every object in Jython is an instance of a class --
    there are no types in Jython. i.e. [].__class__ is a sensible
    thing to write in Jython. <I>CPython should be fixed - but
    don't hold your breath.</I>

    <p><LI>Jython file objects are still missing some
    functionality -- see todo list in (Hopefully in
    the near future this can be changed to read -- Jython file
    objects include the following extra functionality to properly
    handle non-ascii files...) <I>Jython should be fixed.</I>

    <p><LI>In CPython, range(0.1, 3.2) yields the surprising [0,
    1, 2]. Jython does the right thing (reject float arguments).
    -- Many other functions taking int arguments have the same
    problem. <I>CPython should be fixed, but don't hold your 

    <p><LI>The __name__ attribute of built-in extension modules
    (e.g. 'sys') is different. <I>Both behaviors are

    <p><LI>In many cases, introspection yields different results.
    <I>Where appropriate and possible, Jython will adhere to
    CPython's introspection behavior.  Some differences are

    <p><LI>Jython defines __debug__, but always sets it equal to
    1.  <I>Jython should implement CPython's -O option.</I>

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

    <p><LI>Jython doesn't support restricted execution mode and
    doesn't have the magic __builtins__ in every namespace.
    <I>Jython will probably never support restricted execution
    mode -- Java's security model is recommended instead.</I>

    <p><LI>Jython uses different values for the IOError
    argument. This causes trouble for people who unpack the value
    into an (errno, message) tuple. <I>Both behaviors are

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

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

    <p><li>Function objects do not have writable func_code or
    func_defaults attributes. <i>While these are writable in
    CPython, I haven't decided whether they should be writable in

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

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

    <p><LI>The 'b' (binary) flag parameter to the open(file, flag) 
    call have a different meaning for Jython. In addition to the 
    expected platform depending newline translation, the 'b' flag
    also controls the unicode/binary translation of characters with
    value > 255. When the 'b' flag is specified, only the low-order half
    of each unicode character will written to the file and the high-order
    byte will be set to zero when reading from a file. 
    Without the 'b' option, the unicode charecters will the passed 
    through the default codec before going to/from the file.

    <p><LI>The builtin 'chr' function allows values in the range [0..65535].

<h3>Extension modules</h3>

    <LI>Jython supports all Java packages as extension
    modules. i.e. from &quot;java.lang import System&quot; will
    work in any Jython implementation. <I>This functionality
    might be added as an optional extension to some future version
    of CPython.</I>

    <p><LI>Jython includes the builtin module <tt>jarray</tt> -- which
    allows Python programmers to create and manipulate Java array

    <p><LI>Some builtin extension modules don't exist in Jython.
	<LI>The following are under consideration (working code
	would make the decision much easier ;-) -- array, select,
	a dbm/gdbm/bsddb style module, Numeric, cmath. 

	<p><LI>The following are highly unlikely any time soon --
	win32com and Tkinter.  However, Finn Bock has a JNI implementation called
	<a href="">jTkinter</a> which
	supports the full _tkinter API.  Very cool stuff!

	<p><LI>Let me know if something should be added to this

    <p><LI>os module
	    <LI>popen() and system() are missing. <I>Jython should be
	    fixed, patches would be graciously accepted.</I>

	    <p><LI>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.

	    <p><LI>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.

	    <p>Finn Bock has created
	    a <a href="">JNI/C++
	    implementation for the posix module</a>

    <p><LI>The socket module is limited.

    <p><LI>sys module

	<p><LI>Jython is still missing exitfunc

	<p><LI>Also missing executable, getrefcount,
	setcheckinterval which don't make much sense for Jython.


    <p><LI>thread module
	<p><LI>CPython's thread modules defines some aliases that
	Jython's doesn't. <I>These aliases are considered
	obsolete and won't be supported by Jython.</I>

    <p><li>Harry Mantakos has contributed the underlying md5
    implementation, so now the md5 module works out of the box.

    <p><li>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.

<h3>Interpreter and environment</h3>

    <p><LI>Jython doesn't catch interrupts. <I>Only fixable with
    a GUI console since interrupts are not supported by Java.</I>

    <p><LI>Jython doesn't have command line editing. <I>Only
    fixable with a GUI console.  However, Un*x users can check out 
    <tt>rlterm</tt> which provides generic GNU Readline support
    for any terminal based interactive program.  <tt>rlterm</tt>
    is part of the
    <a href="">Yorick</a> package.</I>

    <p><LI>Jython should have a feature similar to
    $PYTHONSTARTUP, which specifies a script to run at the start
    of interactive mode only.

    <p><LI>Jython supports
    <a href="interpreter.html">different command line options</a> than
    CPython, e.g. &quot;-jar&quot; and &quot;-D&quot;.  It
    also has a different convention for indicating non-interactive
    standard input (the Java runtime needs help).