Newsgroup: it.comp.lang
Titolo: [CONFRONTO] Jython e Java

Salve a tutti.
Mi stavo chiedendo quali vantaggi può avere l'utilizzo del Jython
in vece del Java e viceversa per avere infine un .class.
Mi viene in mente che a favore del Java potrebbero esserci i
seguenti punti:
- E' "nativo" per cui potrebbe essere più ottimizzato del Jyhton.
- Ha una base di utenti più ampia, per cui è più facile trovare aiuto
  in caso di necessità.
- Ha una sterminata libreria che non so se può essere totalmente
  usata in Jython.
- Ha ambienti di sviluppo ottimi (JBuilder, Eclipse, ...)
A favore del Jython:
- Ha la sintassi del Python, semplice ed essenziale, ma limitata
  in alcuni punti dal fatto di doversi mantenere "compatibile" al
  Java Bytecode.
Ora mi chiedo: Se i vantaggi/svantaggi sono questi, perchè uno
dovrebbe usare Jython?
Ho dimenticato qualcosa?
Ho sbagliato qualcosa?
-- 
Gerolamo

Ho dimenticato qualcosa?
Probabilmente, il vantaggio deriva dall'unione dei due mondi e delle
due librerie
-- 
Lawrence "Rhymes" Oluyede
http://loluyede.blogspot.com
UGIdotNET - User Group Italiano .NET - 
http://www.ugidotnet.org

 e delle due librerie
Ma tutti i moduli Python sono direttamente usabili in Jython?
-- 
Gerolamo
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

Ma tutti i moduli Python sono direttamente usabili in Jython?
Non saprei..non credo comunque


 fare il deploy su una JVM...per il resto meglio Python puro credo
Sono certamente d'accordo.
Mi stavo però chiedendo se, dovendo sviluppare in un ambiente
nel quale è disponibile una JVM e non un interprete Python e
dovendo eventualmente "dialogare" con altre applicazioni Java,
valesse la pena di usare Jython per avere vantaggi di sintassi,
o se quest'idea fosse sono un modo di complicarsi la vita,
invece che di semplificarla.


invece che di semplificarla.
Non saprei, sinceramente non ho mai provato seriamente.
Comunque credo che se devi lavorare su JVM tanto vale usare Java
Se proprio vuoi usa Jython se conosci bene Python
Se invece devi solo dialogare con app Java..beh dipende da cosa
intendi per dialogare...non so quanto Jython ti possa aiutare


 Ma tutti i moduli Python sono direttamente usabili in Jython?
I moduli scritti in Python puro sono compatibili con entrambi. 
(Considera che il supporto al linguaggio in Jython e' all'incirca 
equivalente al CPython 2.1 o al 2.2, quindi alcune features recenti - 
metaclassi, ecc. - possono non essere presenti o funzionare in modo 
differente).
I moduli scritti in C devono essere riscritti in Java per funzionare con 
Jython.
-- 
Roberto Lupi

 intendi per dialogare...non so quanto Jython ti possa aiutare
Jython puo' essere utile, ad esempio, come linguaggio per la 
personalizzazione dell'applicazione (lo stesso ruolo che ha VBA in MS 
Office, per intederci).
Io lo trovo comodo per sperimentare con le librerie Java, grazie al 
prompt interattivo.
Lo uso anche per scrivere qualche unit test, sostituendolo a JUnit in 
due casi specifici: (a) quando l'equivalente scritto in Java 
richiederebbe molto piu' codice (ad es. quando si devono definire molti 
mock objects) e (b) quando sto scrivendo codice Java che si deve 
integrare con un'applicazione in CPython (es. applicazione Python/Zope 
che chiama componenti in Java/JBoss; quando si deve parlare con librerie 
proprietarie disponibili solo in Java, questa e' l'unica strada).
-- 
Roberto Lupi

 con Jython.
Sei stato chiarissimo, grazie.


 Uh... "funzionare in modo differente" mi pare brutto...
Ecco un sunto delle differenze fra Jython-2.0 e CPython-2.0 preso dalla 
documentazione di Jython.
Ora siamo alla versione 2.1 di Jython che dovrebbe essere all'incirca 
equivalente alla 2.1 di CPython, alcune cose sono cambiate ma la maggior 
parte dei punti rimane valida.
------------- 8< ------ CUT HERE ------ 8< -------------
This list has been updated to describe the differences between Jython-
2.0 and CPython 2.0
Syntax
    * Jython has a different interpretation of floating point literals. 
CPython doesn't allow 001.1 CPython should be fixed.
    * Jython supports continue in a try clause. CPython should be fixed 
- but don't hold your breath.
    * 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'. Both behaviors 
are acceptable. 
Standard types, functions and behavior
    * 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. Both behaviors are acceptable.
    * 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. Both behaviors are acceptable.
    * 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. Both behaviors are acceptable.
    * In Jython, 0.1**4 is printed as 1.0000000000000002E-4. In CPython, 
it is printed 0.00010000000000000005. Both behaviors are acceptable.
    * Jython sequences support three argument slices. i.e. range(3)[::-
1] == [2,1,0]. CPython should be fixed.
    * 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. CPython should be fixed - but don't hold your breath.
    * Jython file objects are still missing some functionality -- see 
todo list in PyFile.java. (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...) Jython should be 
fixed.
    * 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. CPython should be 
fixed, but don't hold your breath.
    * 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, Jython will adhere to CPython's introspection 
behavior. Some differences are acceptable.
    * Jython defines __debug__, but always sets it equal to 1. Jython 
should implement CPython's -O option.
    * The locals() dictionary in Jython is mutable from within a 
function. After "def foo(x=1): locals()['x'] = 2; print x" 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. Proper behavior here is still 
unclear.
    * Jython doesn't support restricted execution mode and doesn't have 
the magic __builtins__ in every namespace. Jython will probably never 
support restricted execution mode -- Java's security model is 
recommended instead.
    * Jython 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.
    * Jython 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 Jython 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 Jython 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 Jython 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 Jython.
    * Jython has "true" 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.  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("foo", 'r').read() excessively. Both 
behaviors are acceptable -- and highly unlikely to change.
    * 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 "class c: pass", c.
__dict__[1] = 2 will work in CPython, but will raise a "TypeError: keys 
in namespace must be strings" error in Jython. Both behaviors are 
acceptable -- CPython might adopt Jython's approach in the future for 
the performance gains it can provide.
    * 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.
    * The builtin 'chr' function allows values in the range [0..65535]. 
Extension modules
    * Jython supports all Java packages as extension modules. i.e. from 
"java.lang import System" will work in any Jython implementation. This 
functionality might be added as an optional extension to some future 
version of CPython.
    * Jython includes the builtin module jarray -- which allows Python 
programmers to create and manipulate Java array objects.
    * Some builtin extension modules don't exist in Jython.
          o The following are under consideration (working code would 
make the decision much easier ;-) -- array, select, a dbm/gdbm/bsddb 
style module, Numeric, cmath.
          o The following are highly unlikely any time soon -- win32com 
and Tkinter. However, Finn Bock has a JNI implementation called jTkinter 
which supports the full _tkinter API. Very cool stuff!
          o Let me know if something should be added to this list. 
    * os module
          o popen() and system() are missing. Jython should be fixed, 
patches would be graciously accepted.
          o 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.
          o 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 
    * The socket module is limited.
    * sys module
          o Jython is still missing exitfunc
          o Also missing executable, getrefcount, setcheckinterval which 
don't make much sense for Jython. 
    * thread module
          o CPython's thread modules defines some aliases that Jython's 
doesn't. These aliases are considered obsolete and won't be supported by 
Jython. 
    * 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
    * Jython doesn't catch interrupts. Only fixable with a GUI console 
since interrupts are not supported by Java.
    * Jython 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.
    * Jython should have a feature similar to $PYTHONSTARTUP, which 
specifies a script to run at the start of interactive mode only.
    * Jython 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). 
------------- 8< ------ CUT HERE ------ 8< -------------
-- 
Roberto Lupi