Slashdot Mirror

Python is completely object orientated (like Java) but unlike java it doesn't force you to use objects. Hello world in Python looks like this:

print "Hello world!"

Although in python everything is an object (even class definitions are stored internally as "class objects") you don't need to know that, or even know OOP, in order to write a python script - you can just write procedural code instead.

Python is completely cross platform compatible, open source, fast, has a growing number of real world applications (Zope is just the beginning) and can even be used to write Java via jpython (www.jpython.org). It's got an interactive interpreter which is great for complete beginners to programming to try stuff out, and although it's easy to get started it has some fantastic advanced features as well(like the way you can use dir() and similar functions to get complete access to python's inner workings - what names it has defined, what objects have been created, what it had for dinner...)

Finally, it was named after Monty Python's Flying Circus and has a healthy sense of humour to boot - what better way to get students interested in programming?

Where Microsoft betters Sun is that while Java is the only real language that compiles to the JVM, Microsoft intends IL to be cross-language.

It's already been pointed out that this statement isn't true. Here's why, for those of y'all that don't already know. :)

First off, Java isn't the only programming language (or even the only "real" programming language) which works with JVM. One can point to JPython as an example of a language which works with JVM. (Of course there are many out there who think Java isn't a "real" programming language. I'm not going to argue with them too vigorously, execpt to say that if BASIC on the Apple was a real language, then there's no reason why Python shouldn't be, either.)

The second reason, which is more substantial, is that JVM, while not exactly an open standard, is pretty much available to the public. In particular, the byte codes are well-known. While it's not trivial to port a language to a new instruction set, it's far from impossible. The only reason why there isn't, for example, a JPerl, JSmalltalk or JOberon, is because nobody's done the port.

Microsoft does have a vested interest in making .NET as widely useable as possible. That will probably include porting other languages to .NET, and maybe the unthinkable, porting .NET to other operating systems. Then all they'd have to do is keep .NET proprietary (but sell, for example, a standardized .NDK for people who want to port their favorite languages to .NET) and they could make a killing off the platform. Then it would be Microsoft versus Sun. A very ugly battle indeed.

ObJectBridge (GPL'd Java ODMG) needs volunteers.

ObPythonPostInPerlThread:

Python will also be part of .NET along with Perl, and it can do SOAP as well. Moreover, JPython already makes Python a Java platform language. In other words, it doesn't matter who "wins" the cross-platform war, Python is already there.

import java.io.*;

cooler = System.out.println

cooler("Python Rules")

Burris

I personally like C, Java AND python 'cause each have its own merit. I use whatever got the job done best. Ever heard of jpython/jython? It's like the best of both dynamic and static worlds. To me open source is about open-mind. I'm learning Objective Caml right now :-)

Come on folks, I know there's an anti-Java contingent out there but when you discuss non-C implementations of Python you really shouldn't omit JPython.

Some key differences between JPython and CPython:

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.

• 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.

• 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.

This is how. Not much on Lisp, but quite a bit for Scheme. There are also many other languages listed at that site that have been made to work inside of Java. I know that JPython is very popular!

Look here.

See my related post on this!

Most of my work is Java-based, but I can use JPython to script using my Java classes, which makes life very easy. Test harnesses are a doddle, and I can interrogate my class via an interactive prompt

eg. I can never remember the formatting strings for SimpleDateFormat. With JPython I just play around at the prompt until I've got what I want, and then paste the format string into my main project.

I can also write CORBA-enabled scripts, and interrogate my servers interactively.

Much as I love Perl, I don't think Python (or JPython) can be beaten for this!

But it's impressive that you can write a C# class and then subclass it from VB or Python, and vice versa; this is a degree of unification which languages on Unix badly lack.

Check out JPython. You can subclass Java classes in Python, then subclass yourPython classes in Java.

One of the best things, however, is the JPython interactive shell. It is a fantastic way to prototype and play with Java; interactive access to Java classes! woo hoo!

JPython is way cool.

Burris

Microsoft executives said the new language, an easier-to-use version of the popular C++ language, is intended to drastically simplify and speed up software development as well as promote the company's Next Generation Windows Services (NGWS) initiative.

Any language that's a hybrid of C and C++ can't possibly "simplify" development of anything, especially for those VB point and drool types. How the hell do you make a hybrid of C and C++ anyway?

While sources say C# will include several features apparently modeled on some of the most popular features of the Java programming language, Microsoft executives say the language is not a Java competitor. "This is not a response to Java," Goodhew said.

One word: bullshit.

One source familiar with Microsoft's plans said C# is "intended as (a way to foster) new styles of development. Combine it with the Web services (Microsoft) is announcing and you get powerful stuff. It also so happens to effectively mirror what Java can provide. It provides operating system independence (which Java provides), but it also provides language independence, which Java can't provide."

Woah...hold on a second here. This is going to be os independent? What other OS's will it run on? How is it going to run? They say Java can't provide language independence? Obviously they've never heard of JPython or any of the other languages that have compilers that can translate high level source code to Java bytecode that will run on a JVM.

In spite of all the hoopla, we'll see how long it takes for this to move out of the vapor stage, if it ever does...

Looks like a Microsoft press statement to me. Keep your eye on these Python folks.

I'm hoping to help the JPython effort by extending it to take full advantage of the robust Java platform, as I think that Python is an excellent technology which should be integrated with Java. Java and Python. A killer combination.

- Sun Certified Programmer for the Java Platform

- Sun Certified System Administrator for Solaris

Granted, it isn't quite as straightforward as Objective-C, since you are forced to define interfaces. I, too, would have preferred these features to be as straightforward in Java as in Objective-C. But you lose some and you win some: on balance, Java has runtime safety and Java's reflection API is more complete and better specified; on balance, I think that's not a bad tradeoff.

Incidentally, there are more dynamic distributed object systems for Java, including Sun's own JavaSpaces, as well as some of the XMLRPC implementations.

Incidentally, both JPython and Bistro give you a very Smalltalk/Objective-C like object model on top of the Java runtime. Bistro just uses reflection, which has significant overhead. JPython actually does a lot of analysis to make some method invocatinos faster. I believe it's possible to do even better and essentially support Smalltalk/Objective-C object semantics completely and portably in Java.

The other thing to keep in mind is that Sun, unlike Apple/NeXT, has publically stated that independent reimplementations of their software and APIs are fine with them (their battle with Microsoft is over trademarks and licensing terms, not the right to clone Java).

Speed and cross-platform compatibility are necessarily opposed.

IMHO JAVA is rather a poor language, with many niggling and unnecessarily clumsy constructs. It is too similar to C/C++.

However, I think the universal bytecode it supplies may be its real future. There are a number of compilers which take source code in other OO languages and generate JAVA bytecode: for example, AppletMagic (for ADA), IBM's NetRexx, and a version of Python.

I've used NetRexx, though I've no expertise in the others. I found it far easier to write simple stuff, and no harder to write complex stuff, in NetRexx.

I agree that "run everywhere" has failed. But "one universal bytecode" may be the language's future. Five years from now we may see JAVA largely a server-side language. Classes in JAVA bytecode will be created using compilers that take JAVA, ADA, PYTHON, RUBY, LISP . . . you name it. If these classes are applets, they will be served out to browsers in JAVA bytecode form. The majority of these classes, however, will run as servlets or JSP's. They will be recompiled to the server's native code (the native code compiler takes the JAVA bytecode as input) and will run at high speed.

Qualifier: I have on;lytheoretical knowledge of PYTHON or LISP - it may be that the internal logic of these languages forbids or handicaps translation to JAVA in the ways I have sketched out.... Enlighten me .....

There are several different implementations of Python, but the most notable are CPython (Original Python) and JPython. JPython is an implementation of Python in 100% pure Java. Python scripts run anywhere there is a JVM (though you need the JPython jar and probably the Python class library). Furthermore you get complete access to Java from within Python. You can instantate and send messages to any Java class. You can even subclass Java classes in Python. You can use the Python interactive mode to interactively manipulate Java classes. It's way cool! In my opinion, it is the best way to deal with Java. Python becomes a higher level langauge on top of Java.

Anyone who is forced to use Java (which is becoming more and more politically correct every day) would be wise to check out JPython.

Many people complain about Python's use of relative indentation but those people typically don't use python. It really is a complete non-issue for people that use Python. Let's face it, cutting and pasting code when using an Object Oriented language is Bad Form.

Note that it is indeed possible to defeat the indentation if necessary. Check out this implementation of a CBC (Cipher Block Chaining) mode Karn cipher in Python (using MD5 for the hash function). The key and IV are crunched with MD5 before usage, so they can be of arbitrary length and density.

Usage: karn -e "key" "initialization-vector" | karn -d "key" "initialization-vector"

from md5 import *;from sys import *;from string import *;M=md5;il=ir=M(argv[3]\ ).digest();ki=M(argv[2]).digest();K,k=ki[:8],ki[8: ];p=stdin.read(32);c={'-e':'\ l=x(l,il);r=x(r,ir);R=x(M(l+K).digest(),r);L=x(M(R +k).digest(),l);il=L;ir=R','\ -d':'L=x(M(r+k).digest(),l);R=x(M(L+K).digest(),r) ;L=x(L,il);R=x(R,ir);ir=r;il\
=l'};main="def x(a,b):return joinfields(map(lambda m,n:chr(m^n),map(lambda m:o\
rd(m),a),map(lambda m:ord(m),b)),'');\nwhile(p):p=ljust(p,32);l,r=p[:1 6],p[16:\ ];exec(c[argv[1]]);stdout.write(L+R);p=stdin.read( 32)";exec(main)

I have to second this Python recommendation. You can get the best of both worlds with Python. You get the ease and quick development time of Perl and other scripting languages combined with good OO design and the (relative) power of a standard language. In addition, JPython is 100% Java and can be run with any JVM. Without knowing your reqs, it definetely deserves a look. Then again, what do Anonymous Cowards know.

yes, python is interpreted, but you can also compile it to java bytecodes, and have full access to java libraries. see JPython
Nahuel.

Amen -- Python is a beautiful language that is powerful and flexible and (most importantly) eminently readable!

I was blown away when I heard about JPython the other day. This will allow you to load and interact with Java objects on the fly, in the interpreter. When you're done you can stream it all out to disk. It's like a toy shop :)

Plus, the Win32 API and COM is exposed under Python too so you can take your pick. (Or Tk for the Unix folk.)

Anyway, If I wanted to read code that looks like Perl, I would 'cat' a core dump.

Do you care how well it works

Yes, at least up to a point; if it works too poorly, what's the point?

& does java applet based systems count?

No. A Java applet is just a small locally-run application that happens to be written in Java rather than in some other language (or, perhaps, "that happens to be distributed in the form of Java bytecode" - something distributed in Java bytecode form wasn't necessarily written in Java, as there exist compilers that translate other languages into Java bytecodes, e.g. the JPython compiler) and that happens to use whatever toolkit the environment in which it's running provides. Interesting, potentially cross-platform (if you don't manage to use some platform-specific classes, say), but not the same as the examples many people were giving, e.g. Slashdot or Web mail and calendar systems, wherein "the web is the interface" - if your browser happens to pop up some Java applet that handles input events, I/O, etc. itself and provides its own UI with its own code, the Web isn't the interface, it's just the pipe over which the code for that application was delivered, and perhaps the pipe over which it talks to some server, but if that's sufficient to make the Web the interface, a boring old "widget-centric/shrink-wrap" application downloaded via HTTP "makes the Web the interface" as long as it includes HTTP client code that it uses for some operations.

(Besides, I rather doubt you can make a "Java applet-based" version of the GIMP, or of the other applications/suites I mentioined, for one simple reason - by the time you're done, it'll probably be too big to be called an "applet". "Applet" isn't short for "application written in Java" or "application delivered as Java bytecodes"; the "let" part is a diminutive, indicating that it has to be a small application before it gets to be called an "applet".)

I don't understand why (you probably mean statically typed, you can't add a string and a list in Python either).

I actually think Python is pretty cool, even though I don't know it very well. I just think that given the capabilities of Java and the role of Java in the marketplace, Java was at least worth mentioning.

Well that's why there is JPython (a Java implementation of Python), so that among other things, you can test your Java objects in with short edit-test-edit-test cycle. You can write Python code running on most Java implementation and interacting with its objects ! (isn't what C++ is achieving with C ?).

With python, the object is the way, the truth, and the light. Let no man cometh unto his data save through the object. In perl, OO is an option, not a requirement.

Hmm? You can quite happily store your data in interwoven dictionaries, lists, and tuples if you like, and never write a single class. If you want to talk about classes being a requirement, talk about Java.

With python, you cannot generate C code to compile into an a.out.

With python, the pattern matching is not tightly integrated into the language. It is merely loosely bolted on, which introduces inefficiencies and quoting clumsinesses.

True, but it also means you can leave it out if pattern matching isn't of interest to your application domain. People who want to run massive numeric simulations, build virtual environments, or run a large online role-playing game may not care about processing text. (Coincidences are funny things; while checking the third link, I went to reference.com and was startled when my search pulled up Python code on my screen -- someone forgot to make a CGI script executable, I suppose. reference.com is an application that does care about text searching, I would imagine.)

The greatest problems with regexes in Python 1.5 are:

1. Parts of re.py are still written in Python, not C, and are therefore slow. Fixing that is on my list for 1.6.
2. PCRE doesn't do a lot of optimizations and analyses. Mostly this is because the compiler doesn't build a parse tree and traverse it, but instead tries to construct a string of bytecodes in a single pass.
3. Unicode regexes are an open issue at this point. I've been casting longing glances at the regex engine in Mozilla, which does build a nice parse tree and supports Unicode, and hope to work on splitting it out into a separate library.

With python, you cannot determine your calling context, nor behave differently dependent upon the same.

With python, writing an eval string is a pain in the royal butt due to the insane whitespace problem.

With python, you have no equivalent to Apache's mod_perl.

When Java was first introduced, there was much excited chatter about it killing off other languages; I think Sun is still half-heartedly arguing that. Yet interpreted languages have adapted to Java quite nicely, thank you -- consider Jacl and, of course, JPython. So get used to the diversity -- it doesn't look like it'll be going away, particularly since component architectures like COM and CORBA grant a lot more flexibility in choosing a language.