[Tutor] Slightly OT - Python/Java

[Kent Johnson]

Chad Crabtree wrote:
> I just wanted to let everyone know a  detail about Jython.  It is not
> in 
> fact an interpreter written in Java it is a dynamic Python to 
> JavaByteCode compiler.
> At least that's how I understand this document. 
> http://www.jython.org/applets/issues.html 
> I found this interesting and I thought you all might find it useful.

This is true but it misses part of the picture and to a user it is an insignificant implementation 
detail.

Jython is a Python to Java byte code compiler plus a runtime system.

Jython actually builds a whole object model to represent the Python runtime environment. There are 
objects representing Python classes, objects representing Python objects such as strings, lists, 
dicts, etc. Objects representing modules. and so on. Loosely speaking, this is similar to what the 
CPython runtime does.

Jython code is compiled into Java byte codes that make heavy use of the runtime system. CPython code 
is compiled to Python byte codes that are interpreted by the CPython runtime. So it is correct to 
say that Jython is not an interpreter written in Java; it uses the interpreter that comes with Java 
(the Java VM). But to say it is (just) a dynamic compiler misses a big part of the implementation.

To a user, none of this makes any difference. Jython is syntactically and semantically almost 
identical to CPython 2.1. You can use Jython interactively just like Python. You can run many of the 
same programs. The implementation details are quite different, but it is the same language.

Max Noel wrote:
 >> On Jan 10, 2005, at 20:04, Alan Gauld wrote:
 >>> And the lack of functionpointers (inner classes not withstanding)
 >>> is a big hit, and what about multiple inheritance - interfaces suck!
 >>
 >>
 >>     True, the lack of function pointers is a problem, at least when
 >> working procedurally. When going full-OO, I don't see where this can
 >> be a problem (since Class itself is an object, you can create pointers
 >> to classes).

Most, if not all, uses of function references in Python could be rewritten to use interfaces and 
object instances in Java. But function references are way easier to read and code and *much* more 
concise. I use function references constantly in Python in ways I would never dream of using them in 
Java because it just isn't worth the hassle.

 >>     Also, I agree that interfaces are a bizarre way of adding multiple
 >> inheritance. I'm still wondering if there is a better way, though
 >> (apart from just allowing multiple inheritance, which I still don't
 >> know if it's a good idea or not).

Interfaces *don't* add multiple inheritance - you only get one implementation, all the others you 
have to code yourself or use hand-coded delegation. What a pain! Mixin classes can be very useful.

 >>>> Also, Java has something which Python lacks (yet should have):
 >>>> private/protected/public class members. In Python, everything is
 >>>> public, which I consider to be a Bad Thing(TM).
 >>>
 >>>
 >>> Why do you think it should have it? Have you run into a lot of
 >>> problems with inappropriate access in Python programs? This often
 >>> comes up from ex Java/C++ programmers yet access control like
 >>> this was not part of any of the earliest OOP languages and nobody
 >>> ever discussed it much(SMalltalk took one extreme - all data
 >>> private, and Lisp the other - all public) But I don't recall
 >>> have any big issues with lack of control, and I don't find
 >>> it an issue in Python.
 >>> What exactly do you find to be such a problem with the lack
 >>> in Python?
 >>
 >>
 >>     Well, the fact that everything is public means that if you want a
 >> certain form of encapsulation, you have to state in the docstrings
 >> what should be used as an "external interface" (stuff like "This is an
 >> internal method and may change/disappear in the next version! Don't
 >> use it!") and hope that people who use your classes listen to what you
 >> say.
 >>     I like the idea behind encapsulation, that you should be able to
 >> use a class as a "black box" with a known interface and not worry
 >> about the specifics. The way things are, Python gives you the
 >> possibility of shooting yourself in the foot; or to be more accurate
 >> they prevent you from preventing others from shooting themselves in
 >> the foot when they use your classes. (does what I say make any sense?)

That's exactly it. Python doesn't give you the means to prevent others from shooting themselves in 
the foot. It *does* give you a few ways to point out where the gun is and where the foot is and to 
suggest that maybe you want to keep the one apart from the other :-)

If you prefix attribute names with _ that is a clear signal to users that they shouldn't use it. The 
public interface of a class or module consists of all the attributes whose names don't start with _. 
In the case of modules, Python gives a little weight to this - module attributes whose names start 
with _ will not be imported with 'from foo import *', and module attributes whose names start with 
__ get mangled by the compiler into something else.

In my work, I'm happy to not have to think about whether an attribute should be private or 
protected, etc etc. Python lets me focus on the problem at hand instead of on the language.

Kent