Slashdot Mirror

For distributing Python apps under Windows, I like to just copy the installed Python runtime environment and include that as a subfolder to the Python app. The app is started using a .BAT file (py\python.exe main.py). This makes it easy to change the installed source. This takes up less than 2.5M. The equivalent py2exe binary takes up about 900K.

It would seem that anything interpreted is going to suffer the "separate download" problem...

Both of these methods gives the end-user a completely self-contained Python app, no extra downloads needed. It is also possible to do this under Linux.

Ease of learning would also be debatable for probably every language out there. I know folks who are wizards with C/C++/Java/perl/$language1 who could couldn't get a working "Hello, world." out of $language2, while at the same time I know others with the skills in $language2 who couldn't do anything in $language1.

I don't agree, I think it is pretty obvious that different languages have varying levels of abstraction. I have an MSc in Computer Science, and 10 years of professional experience writing hard real-time apps in C + an RTOS. There's no question that C (/C++) will be around for a long time, because for low-level programming you just have to have control over the CPU. But this comes at a pretty high price. Most of the C code I've seen is hard to read and understand because there is so much "plumbing" going on for simple stuff, like managing lists of objects, etc.

About 18 months ago I decided I wanted to learn Python, and I started the Freevo project. Freevo is almost exclusively written in Python, and it has turned out to be a really good choice. Some examples:

• Python is very easy to pick up for experienced C programmers. All of the Freevo developers were new to Python before they started working on Freevo.
• Dynamic typing is easier to program with, and it doesn't lead to more bugs.
• The indentation has not been a problem. In fact, I find it quicker to edit Python code compared to C in Emacs since it is easier to change indentation levels for whole blocks of code.
• Python code is generally easier to read since it is higher level than C, and there are no {}; characters cluttering the screen. Spaghetti-coding is still possible of course.
• Python has a very good Unix system call abstraction layer. Everything is available, but in much less code compared to C. For instance, a TCP/IP client/server example
• Python is also good for multi-threaded apps. It is easy to start and communicate with new threads, compared to C and pthreads.
• Execution speed is generally not an issue. And if it turns out to be, it is easier to implement smarter algorithms in Python, or parts of the app can be rewritten in C and called as native functions from Python.

As I said, C/C++ will be around for a long time. But for many new apps that I write, I find that Python lets me write them in 1/10th of the time compared to C (that I know very well). Python also has an amazing ability to work on the first try. I'm sure others have similar experiences with other higher-level languages such as Java, Perl, Ruby, etc.

I'm working on a project for central user management on a popular network appliance. At present there's only one commercial solution (that I could find/google) available that lets you manage n+1 of these appliances at once.

I initially looked at the problem and figured, heck I can do it easily with expect and ssh, but then I started thinking about how my employers & co-workers would use it (I contract), and realised a command-line application wouldn't suffice.

So I started pondering how I could integrate a fairly simple backend (that could be implemented by scripting languages) with a portable interface.

I could either:

• a) Put the backend script onto a webserver, and allow administrators to use it via a web browser and CGI.
• b) Use Python and wxPython to provide a GUI application that runs on windows/unix/mac.
• c) Use Tcl/Tk to provide a GUI application that runs on windows/unix/mac.

I eventually chose the tcl/tk option, because of the following reasons:

• 1. A webserver-based application would require ongoing maintenance of either a new server, or speaking with existing server ops to get our stuff onto their boxes. This didn't fit in with timeframe and would be difficult to maintain and distribute updates.
• 2. wxPython lacks extensive documentation. I'm not going to force myself to join mailing lists and peruse demo code to figure out how it all works.
• 3. Tcl/Tk is well-tested, instantly portable, and documented up the wazoo.

So I ended up choosing a well-documented language for implementation, which has the benefits of being portable, interepeted (no compiling), and easily updateable (email the latest script). Sure it isn't the sexiest solution, but it works and is easy for new developers (the project will be open-sourced when ready) to pick up on where its at.

I'll go off on a different track than the other responses I've seen...

Wouldn't python suffer from roughly the same problem as Java with the JRE? I mean, unless it's compiled (and I'll admit right now, I don't follow python closely enough to know if it has a "compiler" yet), users are going to need to find and download a Python runtime environment of some sort. The latest I've found at python's web site is around 9M. While that's still about 1/3 what a JRE is, it's still either going to be a separate install, or a lot of additional weight to package up with whatever you're distributing.

It would seem that anything interpretted is going to suffer the "separate download" problem... Ease of learning would also be debatable for probably every language out there. I know folks who are wizards with C/C++/Java/perl/$language1 who could couldn't get a working "Hello, world." out of $language2, while at the same time I know others with the skills in $language2 who couldn't do anything in $language1.

It's a shame the linked article's author didn't address what WOULD be an ideal language to use, and enumerate why, but it's probably because any language he did pick would end up sharing criteria with his "these make C/C++/Java bad" statements. :-/

Modern C++ is a wonderful language, at least I think so. But it is much different than the "old" C++, almost to the point of being a different language. So if you've had bad experiences with C++ in the past, perhaps you should give it another look. And C++ is not dead, there are a lot of interesting advancements in the language, and more properly how to use it. There are a whole lot of generic programming and template patterns which are comming out which show that C++ has a lot more power than people ever thought.

Of course C++ does tend to have some problems with Open Source projects, which C usually doesn't have. So I certainly don't frown on C development either. And plain old C is usually very easy to integrate into other languages/environments.

1. C++ compilers are just now catching up to the standard. gcc 3.3 for instance is pretty darn good now, but lots of compilers have lots of problems.
2. C++ can be very slow to compile (or more technically to link), especially as you use lots of templates.
3. The binary ABI is not universal. It's hard to write shared libraries in C++, so it's not as useful for components as it is an entire application.
4. Dynamic linking in of C++ is next to impossible (dynamic linking often uses the dlopen() system calls, and it how most run-time plugin architectures, such as in Apache or Python work).
5. Although in theory C++ is very portable, in practice that is still difficult (usually a victim of poor linkers). C++ which works fine under Linux may have serious problems under say AIX or HP-UX, unless you test on those platforms.

However, C++ is certainly still alive and very viable on a whole. And O'Reilly just published the new C++ in a Nutshell book which covers the ISO standard C++ very well. Also you should look at the Boost Project if you're looking for more advanced C++ libraries (many of the Boost developers actively participate in the C++ standardaization effort, and Boost is often thought of as the testbed for possible language additions for the next round of standardization).

But I do agree, that you need to pick the language according to the project. There is no one best language. When I look for other open source projects with the intent of being able to take advantage of the openness (i.e., modify the code), I tend to look for projects written in Python. I particularly avoid Perl, becuase it is much harder for me to understand. I also avoid Java because it's a proprietary language with no open source JDE/JDK and I think the language sucks when compared to ISO C++. But again, those are my preferences.

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD ^H^H^H^H Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

Floating Point Arithmetic: Issues and Limitations.

• PHP Perl-compatible
• Python re module
• Python re howto

At this site.

Try it. You'll probably love it and never want to go back - that's what happened to me.

I don't understand why anyone is still using lesser languages - Perl is a mess in comparison.

it's somewhat close to the redhat trick of replacing the rpm module redhat_release.
A quick googling brought me this and this.
looks like you can just change the version number in /etc/SuSE-release to "8.2"
(the better way would probably be to install a new suse-release RPM, though I can't seem to find one)

The author claimed that it wasn't a QBasic application, but the error messages when it crashes tell a different story.

The QBasic integrated editor was a real joy, and it's hard to find a good, lightweight equal. Python is too big, C++ lacks the "fun" factor...

Lua with the SciTE editor comes close, if only it had builtin help.

I only stopped using QBasic after repeatedly running into the 32K memory barrier. I moved to Euphoria, a nice interpreted language. I missed the QBasic editor that I ended up writing a clone for Euphoria.

Heck, QBasic left such a mark that I ended up writing a Basic interpreter of my own.

I was asked this question two months ago and for a home schooled high school student and I said python. Because:

• Free
• Lots of good beginners tutorials http://www.python.org/doc/Newbies.html
• The Python for education SIG http://www.python.org/sigs/edu-sig/
• The pygame famework to start modifying existing games/creating new games
• Pycard for creating user interfaces without having to deal with ALL of the grotty details. http://pythoncard.sourceforge.net/

As for Java, that would be fine as well and probably has some similar resources but why start (as mentioned elsewhere in this thread) with a bunch of detail you have to master before you can start getting something done <flame> indeed why get into it at all -- unless you need it </flame>.

I was asked this question two months ago and for a home schooled high school student and I said python. Because:

• Free
• Lots of good beginners tutorials http://www.python.org/doc/Newbies.html
• The Python for education SIG http://www.python.org/sigs/edu-sig/
• The pygame famework to start modifying existing games/creating new games
• Pycard for creating user interfaces without having to deal with ALL of the grotty details. http://pythoncard.sourceforge.net/

As for Java, that would be fine as well and probably has some similar resources but why start (as mentioned elsewhere in this thread) with a bunch of detail you have to master before you can start getting something done <flame> indeed why get into it at all -- unless you need it </flame>.

I'm now firmly in the trenches of middle age, and so have begun to succumb to that tendancy that we all get as we grow older to gaze back upon my life and to tell the kids of today how great they have it now. This usually begins with the phrase Back when I was a kid...

Back when I was a kid, microcomputers were just beginning to be something that my super rich friends could get. Computers like an Apple II, which I had no chance of affording.

Then the Atari came out. Not only was it cheaper, but it had really kick/ass graphics like Star Raiders. So I worked for nearly a year, earned $400 and bought my first computer. I had already learned BASIC on other machines, so I saved a bit longer and got a BASIC cartridge. A few months more, and I had a cassette deck to store my programs on.

About that time I started to learn about how the graphics architecture of the machine worked. I bought a copy of De Re Atari. I got their assembler/editor cartridge and started to write some programs of my own. I read the ROM listings. I remember writing my first truly useful program: a program for copying copy protected cassette tapes so I could backup my copy of Jawbreaker.

I goofed around with that silly computer for years. By the time I was finished, there was really very little about the system that I did not understand. And that's probably the last computer that I truly did understand.

It's simply not possible to understand all the inner workings of a computer like that any more. Or, maybe it is possible, but it simply isn't worth your time. You (or your kid) probably have other things to do with computers, like make web pages, edit photos, or make videos. Computers have become a doorway to doing other things, and like most doorways, people don't give them much thought anymore. I sometimes find that a bit sad, but then I think of all the cool things kids can do. My nineteen year old swears that he didn't want to learn to program, but he has a webpage with all sorts of javascript madness on it. He's made videos. He's photoshopped photos of his friends. In short, he's doing what he likes to do: taking the computer for what it is, and using it to do what he wants. I can't say that I see much wrong with that.

I guess I should give some recommendations for those people whose kids really think they do want to learn how to program. They could do a lot worse than to use Python. It's a fairly reasonable language that is interactive and enables you to do fun stuff nearly immediately. If the kid is interested in making games, they can use Pygame, which I've found to be very pleasant to play with, and is available on many platforms. Download some example games, and then help them figure out how they work. Change some of the graphics to use graphics of their own. Encourage them to share their work with others, perhaps using the web. Answer questions. Be enthused. Help get a club or group started at their school. Be a parent. :-)

Wasn't it designed to teach?

With some Tk in the mix there as well..

And Java is a free download. Heck, if you're programming you're such a nerd you have broadband as well..

And then there's of course javascript. And actionscript (so, kids pirate flash, so big deal.. )

It's all just a download away.. Really, I don't see the big deal. Just because BASIC isn't in ROM anymore doesn't mean you can't get started programming on Windows.

Every computer should ship with Python installed.

Can't imagine a better language to start learning with. And the interactive mode is GREAT for novices.

I would be shocked if anyone tried to claim that the software ESR has written is even comparable in importance to the software RMS has written.

Then prepare to be shocked :). This puzzles me a bit - why is it that you (and quite a few others) seem to think that fetchmail is the only piece of software ESR has written? I mean, it doesn't take that much effort to have a look at his software list, and his projects list. Note the "past projects" - especially "I was heavily involved in the GNU Emacs 19 development (in fact, I was the primary Emacs-lisp library person for about two years during 1991-1993)." The software page also has this quote: "According to RMS's credit list, I appear to have more Emacs Lisp code in the standard Emacs distribution than anyone else but him."

He was also a primary developer on ncurses, and nethack... he's contributed to python... he's contributed quite a bit to the GNU/FSF project in general. Note: "I was one of the original GNU contributors back in 1982-83, and I've been at it ever since." And fetchmail and CML2 are by no means insignificant.

Fetchmail vs. the entire GNU collection [snip]; it's clear which is more important.

Did you seriously think that RMS wrote all of the GNU software himself???? The two most important projects that I believe RMS originated were GCC and of course Emacs (and probably GLibc and the GDB). But a hell of a lot of people have contributed to those (including ESR) - and I don't think RMS has done anything significant on most of them for a while.

I know it's nice and easy to give one high-profile developer all the credit for projects they originated... but that's just not the case here. RMS is an uber-hacker and has worked on a hell of a lot of great stuff - but so has ESR. I think the main distinction between the two is that while RMS originated more major software projects than ESR, Raymond's probably contributed to more.

Pete.

Everytime I use PHP I end up feeling dirty. Mixing the code and the presentation is just not the right thing to do. Content/View/Model is as close as I can tell to being the right thing. I personally have had great experiences with Apache PageKit and you get to use perl. In addition I'm rolling my own system using Python and Albatross. But PHP? Shudder.

I have a wild suggestion. If you want elegant, kludge-free web applications, drop PHP. The very nature of server-page based programming (PHP, ASP, JSP, etc.), the very act of mingling your code with your markup is non-elegant. Unfortunately, there really isn't any way of separating the two in an elegant fashion, so you're sorta destined for a kludge somewhere, but there are better ways.

One kludge I rather dislike about nearly all server-side programming is the necessity of a connection to a relational database. Invariably, you must get into a lower level to get your data; often you are forced to write SQL for your data, and if your database is complex your queries can get pretty convoluted. There are tools to try to make that transparent, but the cure is often just as bad as the disease.

There are better ways, however. Zope, a web application platform based on the Python programming language, is my current favorite. The big feature that I like best about Zope, aside from the excellent builtin security framework (which is head and sholders above PHP, BTW), is the persistent object database -- with it, Zope can entirely eliminate the necessity of an external database. Not that you can't connect to an external database if you really feel like it; Zope has a built in connectivity API, and there are plugins for all your favorite relational databases.

Zope has many elegant means of managing your content, from your standard header-footer includes to context-based acquisition, to the many content management frameworks already built for you on top of Zope like Plone. Zope comes with two powerful templating languages if you don't like straight Python: DTML and Page Templates.

That said, there are drawbacks: Zope is its own server, so you have to find a hosting company that offers Zope if you don't maintain your own servers. Zope.org lists a few free hosts on the main page. Using the object database is great, but because it's transactional your disk space can quickly bloat if you running a website whose data changes frequently, like, say, a popular forum or blog.

As for the language changes... if you left perl for php because perl was ugly (and believe me, I agree), then you should try python. The language is elegance personified. It's a scripting language, so it lacks the performance of Java or C++ for computation-oriented stuff, but the stuff it does, and the simplicity! Often I've seen three short lines of Python code take tens of lines of Java code to accomplish the same task. Python is so readable you rarely need to comment your code if your variable names are well named. It's also fully object oriented, but if you don't like OO for some odd reason, you can do your stuff with just functions.

Wow... what started off as just a few lines turned into a novel. Now I'm all tired and stuff. Can you tell I really like Zope and Python? :)

" You have no idea what you're talking about do you? Java runs on a VM just like python. They are both "compiled" languages; more to the point, Python using C extentions is *WAY* faster than Java."

Python is an interpreted, interactive, object-oriented programming language. It is often compared to Tcl, Perl, Scheme or Java.

There's been extensive discussion of this over on python-dev. Includes some interesting debunking by Python guru Tim Peters, plus another example of the same type of weakness involving backtracking regular expression engines.

These additions seems to put Java on par with C#, but to make a quantum leap in expressiveness you need a dynamically typed scripting language.

Most applications these days can be written in higher-level languages, resulting in 5-10 times less source code compared to Java/C#, and making them correspondingly simpler to code and maintain.

Java doesn't really have a kick-ass companion scripting language. In MS world, VB plays this role. VB is really popular, but (I think most people would agree) a crap language and not really that high level. JavaScript just doesn't seem to cut it (pretty much only used in browsers).

Why doesn't Sun take a hint and phase JavaScript out in favor of a powerful multi-purpose high-level language like Python or Ruby? That'll put them miles ahead of Microsoft in terms of increasing programmers' productivity... and programmers' quality of life.

Python is good at connecting with C/C++/Fortran, but it requires a little bit of extra effort to turn DLLs into modules. There are, of course, tools to help you: SWIG, SIP, pyfort, and others. Once you have python modules, though, they're very pleasant to use.

I don't know what sort of stuff VB has for, say, fetching things from the internet, but I know that Python has excellent stuff there. urllib is great for lightweight fetching, and you can get heavyweight if you need to. There is a simple HTTP server class, and in fact there are classes for a lot of things that fit beautifully with the rest of the language.

There are some modules fot python that may be particularly useful for research like Numeric and SciPy, and I seem to recall some biology module for python. I don't know what VB has in their place, but I'd bet that it wasn't as pleasant to use.

Different languages, different things. But given a choice, I'd pick Python.

I heard somewhere that NASA is using Python for some stuff. Good choice.

You mean this:

"NASA is using Python to implement a CAD/CAE/PDM repository and model management, integration, and transformation system which will be the core infrastructure for its next generation collaborative engineering environment. We chose Python because it provides maximum productivity, code that's clear and easy to maintain, strong and extensive (and growing!) libraries, and excellent capabilities for integration with other applications on any platform. All of these characteristics are essential for building efficient, flexible, scalable, and well-integrated systems, which is exactly what we need. Python has met or exceeded every requirement we've had," said Steve Waterbury, Software Group Leader, NASA STEP Testbed.

From http://www.python.org/Quotes.html.

Inline::C and Inline::Java are amazing, but they're for calling C and Java code from Perl, for heaven's sake! You should ask: What the hell are you doing writing Perl code in the first place??!

Turing completeness proves you can construct arbitrarily complex rube-goldberg devices in any language. But the point is to choose a language that doesn't force you to stretch it so far, just to do the simple tasks that you need to do often.

SWIG is not a 100% solution, and the features it supports are not the same across all extension languages. When you use SWIG for any non-trivial task, you still end up writing a bunch of typemaps, glue code and convenience functions for "impedance matching". I wrote a SWIG interface to the Microsoft Speech API that was about 1500 lines of SWIG, and 1500 lines of glue code.

So even with SWIG, you still have to compare the quality and usability of Perl's extension API with Python's extension API. And Python's extension API wins hands down. The anonymous coward who claimed that using XS was "painless" must be totally numb from the self-flagilation required to use it.

In a discussion about the design of the "Parrot" runtime, Eric Raymond parenthetically pointed out that:

"(One important place where I think everybody understands the Python side of the force would clearly win out in a final Parrot design is in the extension-and-embedding facilities. Perl XS is acknowledged to be a nasty mess. My guess is the Perl guys would drop it like a hot rock for our stuff -- that would be as clear a win for them as co-opting Perl-style regexps was for us.)"

-Don

"the authors flat out admit they think it is unfair that only so few of us get to have one foot in Perl and one in C"
(Few people use Perl with C because it's extremely difficult.)

"break down that barrier with lots of annotated code examples"
(If the barriers weren't there in the first place, we wouldn't need this book to corrageously "break them down". It shouldn't take "lots" of "annotated" code -- that's a maintainance nightmare!)

"However, wading chest-deep into XS and the Perl internals is not for the faint of heart."
(This is my point! It's much easier and more maintainable to use Python and SWIG instead.)

"Then the text seems to throw us a curve by leaping off into building Perl modules. But there is method to the madness: building Perl modules correctly is inextricably linked to XS."
(What is this XS we have to deal with, then?)

"Perl XS is acknowledged to be a nasty mess. My guess is the Perl guys would drop it like a hot rock for our stuff -- that would be as clear a win for them as co-opting Perl-style regexps was for us." -ESR

-Don

I completely agreed with Graham's article. I know his tool of choice is LISP, but as I was reading the text, my epiphany with Python kept coming to my mind. I used to hack PHP too, but I don't any more. PHP is better than the alternatives in the Web-building niche, but it's not either as general-purpose or as scalable (in terms of project size) as Python --my toy newsbot in my .sig is 100% pure Python, all 20kLOC of it... I could go on and on about Python, but that will hardly be as persuasive as going over to python.org, reading the tutorial and writing some simple short project in py. You will be converted in no time...

You don't outgrow SourceForge. Look at some of the projects hosted there - ViM, Python, several Kernel patches, and much more. Some of the projects there are open-source behemoths, with millions of users.

Yeah, but at least one of those projects is looking for other hosting. There has been discussion on the python-dev mailing list lately about moving away from SourceForge.

Personally, I think that SourceForge is a great tool for small developing projects. It is pretty versatile and works pretty well. However, for a project as large as Python, a more customized and set of development tools may be able to help development. And although SourceForge works pretty well, it's not perfect. Anonymous CVS access only rarely works lately, for example.

You don't outgrow SourceForge. Look at some of the projects hosted there - ViM, Python, several Kernel patches, and much more. Some of the projects there are open-source behemoths, with millions of users.

Yeah, but at least one of those projects is looking for other hosting. There has been discussion on the python-dev mailing list lately about moving away from SourceForge.

Personally, I think that SourceForge is a great tool for small developing projects. It is pretty versatile and works pretty well. However, for a project as large as Python, a more customized and set of development tools may be able to help development. And although SourceForge works pretty well, it's not perfect. Anonymous CVS access only rarely works lately, for example.

Hmmm...nine responses to this thread. Looks like the entire global community of Ruby developers has checked in...

Do yourself a favor and learn Python.

Actually, as of Python 2.2, with nested scopes implemented, g() can really access the variable outside its own scope.

The problem though is similar to what you alluded to with passing variables into functions and wanting the functions to modify them; when in the inner function you say "x = 50", you're rebinding the local-to-g version of x. The end result is that the outer x is then not repointed to the new object. (See the PEP for why, or look at the appropriate part of the "what's new" document)

In any case, this will work in Python 2.2, or in Python 2.1 that uses the proper "from __future__" construct:

def f():
x = [50]
def g():
x[0] = 40
g()
print x[0]
f()

A possible way to think about this is that in python, assignment is not a setq but rather a defvar.

Actually, as of Python 2.2, with nested scopes implemented, g() can really access the variable outside its own scope.

The problem though is similar to what you alluded to with passing variables into functions and wanting the functions to modify them; when in the inner function you say "x = 50", you're rebinding the local-to-g version of x. The end result is that the outer x is then not repointed to the new object. (See the PEP for why, or look at the appropriate part of the "what's new" document)

In any case, this will work in Python 2.2, or in Python 2.1 that uses the proper "from __future__" construct:

def f():
x = [50]
def g():
x[0] = 40
g()
print x[0]
f()

A possible way to think about this is that in python, assignment is not a setq but rather a defvar.

Sure, Python isn't a speed devil, but it's fast tnough for most purposes. Also its memory footprint is at least better than common Java VMs. :)

Python doesn't have macros. Talking about macros identifies you quite reliably as a Lisp programmer with a grudge as all that popularity should go to lisp, dammit! Python has a syntax which allows for a clear expression and recognition of common idioms than Lisp though.

Python has had statically nested scopes for a while, which means (somewhat limited) closures:

PEP 227

You can also use objects to simulate them. I've used objects to simular higher order functions as well quite nicely.

I don't think the vast majority of Python programmers are ex-perl programmers. I don't have statistical evidence for this assertion, but I think the burden of evidence here is on you anyway.

Python does have numeric and numarray for scientific numerics, and more. numeric has been around for years so I wonder how you missed that. Oh, it wouldn't be 'good', of course. :)

As to the object system I can't really comment a lot, I can just say that I don't find myself limited by it at all. There are also quite a few metaclass based systems out there that demonstrate its flexibility. You haven't shown how Python's design limits developers and how it does the worst of both worlds.

Sure, Python isn't the fastest, but we already agreed on that. It's just fast enough for a large quantity of purposes.

So, to me Python is a nice language with just enough syntax, but not too much. It allows clear idioms with its built-in higher level datastructures, while allowing a lot of flexibility if you need it as well. Its standard library comes with a lot of useful things.

Python also interfaces with C, C++ and Java systems nicely, and is designed to work with the environment instead of endlessly layering on top of the underlying systems, which makes the language more heavy weight and harder to integrate.

Python is orthogonal where it counts, but also pragmatic where that counts. It's not particularly appealing theoretically, but it just works well in practice.

Python has a vibrant community of users as well,
an asset that shouldn't be underestimated.

Python is a powerful language that does lots of things well in an easy to understand way. It doesn't excell in any department and isn't pure, but it's very well balanced overall and that's why it can be a joy to work with.

If you need more speed than native Python provides, you can always write code in C and wrap it so it is callable from Python. The wrapping is really easy to do, once you have understood the general concepts involved in it. The product I currently work on has about 10000 lines of C code (crypto and networking) which is used this way, and it works perfectly. For more information about extending Python with C, see:

Extending and Embedding the Python Interpreter

Python/C API Reference Manual

If you need more speed than native Python provides, you can always write code in C and wrap it so it is callable from Python. The wrapping is really easy to do, once you have understood the general concepts involved in it. The product I currently work on has about 10000 lines of C code (crypto and networking) which is used this way, and it works perfectly. For more information about extending Python with C, see:

Extending and Embedding the Python Interpreter

Python/C API Reference Manual

Exceptions are a means of breaking out of the normal flow of control of a code block in order to handle errors or other exceptional conditions.

In the nested while cases above, the FinishLoop exception should only occur very infrequently -- once per entering the whole loop structure, and then only if the while conditions don't fail. The penalities of occassionally raising an exception are not that bad under Python.

Should you return later, and add another inner loop (either a for-loop or another while loop), then it's quite obvious that the exception will still take you entirely out of the nested loops. Under your PHP example, all your continue statements would have to be adjusted to the correct nesting level. It might be easy to overlook one, possibly causing obscure bugs.

That being said, Perl is at least useful for many things ("practical," I believe it's called).

Python is useful for many things as well, as evidenced by the number of people who use it, including Boeing, Disney, Hewlett-Packard, Industrial Light & Magic, Intel, JPL, Lawrence Livermore Labs, NASA, and Yahoo. Programmers at places like these are usually allowed to make their own decsions about their tools, and they chose Python. These guys are good. They don't use tools that they don't like. This is not to say that Python is their only scripting language. I know NASA makes good use of TCL, and probably uses Perl as well.

Peter Norvig says "Python has been an important part of Google since the beginning, and remains so as the system grows and evolves. Today dozens of Google engineers use Python, and we're looking for more people with skills in this language." Norvig is director of search quality at Google. Look at his home page (www.norvig.com/. When a guy who writes AI books talks up a language, it means something. I'm not saying it means everything. It's another piece of data to put on the scales.

Finally, I note that the Google jobs page mentions Perl 11 times and Python 15 times, for what it's worth. I didn't read the job descriptions.

% wget http://www.python.org/ftp/python/2.2.2/Python-2.2. 2.tgz

% gunzip Python-2.2.2.tgz
% tar -xf Python-2.2.2.tar
% cd Python-2.2.2
% ./configure
% make install

It is my philosophy that everyone should learn to program. Not only does programming gain you a greater understanding of computers, but you also get a deeper understanding of mathematics, and the American school system is horrible at teaching both of those.

Go to the Python web site, find some good tutorials, and give them that. Once they learn Python, give them PyGame, and let them code play around.

Let me default this comment by saying that I am big OO proponent.

The experience referenced in this message has nothing to do with the fact that an OO program was used, it had to do with NIH (Not Invented Here) syndrome. NIH predates OO, and exists in all programming paradigms. The failure of this consultant was in his understanding of OO, but in basic software engineering principles such as using libraries.

There are plenty of well-documented instances of oevrly complex/decomposed object models, but the exampled cited here does not qualify.

Finally, I contend, as troll fodder, that a well-written/designed OO implementation is just as compact and efficent as its procedural equivalent. It all about the paradigms that makes the most sense to the designer and programmers, and to imply the OO is not a good, general approach to solving both samll and large problems sound take a peek at Python.

Sun Microsystems made claims of an incredible language that just weren't true. They claimed the language would be revolutionary and that software written for it could work everywhere. Partially true but no one wants a slow computer either. The whole reason people buy new computers is for speed.

Java is not liked nor used by everyone. No one wants it on their computer. No one wants large apps written in java.

Don't be part of the herd mentality. Just because Sun or Microsoft tells you to use their software doesn't mean you have to use it.

Try these languages if you don't like java.
modula-3
squeak
netrexx
rexx
euphoria
python
xbasic.org
tcl/tk

squeak
netrexx
rexx
euphoria
python
xbasic.org
tcl/tk

To really ease kids into python, be sure to check out the turtle module first. (ahhh... the memories)

Macromedia deserves some credit for staying in tune with the development world. But lets face it: Flash is for art majors. Even with its "standard" controls that are now available (e.g., scrolling text box), it is still a difficult environment to control; you always feel like "this could look so much better with this spinning, pulsing button." All those vector calculations in Flash still bring a PII to its knees. If people are interested in Web applications, they migh consider Runtime Revolution, a cheap ($300) cross-platform (Mac, Win, Linux, etc.) alternative with native support for sockets and other amazing tools, including multimedia support, that really allow you to accomplish what needs to be done. I've spent a LOT of time trying to find the right rapid application developement tools for the job, and Runtime Revolution has yet to be beat. Python with Boa Constructor (v .2) and Mcmillan installers is certainly awesome, but the multimedia (i.e., Quicktime) just isn't there yet. In other words, there are a lot of very nice alternatives to Flash, which is really not much more than a glorified banner advertisement tool.

I think it took around 3 generations of C++ Compilers to find the first who did templates correctly.

Do you really expect that templates will work correctly in Java 1.5?

Isn't there a GNU compiler for java? Why doesn't the developers of java programs mention this ?

If you want to see real speed in a interperated compiled language try xbasic

We shouldn't need to buy a new computer just to run a computer language.

I think part of the reason Python is so popular is that it is extremely easy to embed it in a C language application. It really changes your view of coding an application: organize everything into low-level highly optimized C code and high-level Python code. Your C language application becomes a toolbox of functionality available from Python. This approach makes your application totally scriptable by default. I usually take this architecture one step further and create an even higher level, eaiser to use interface purely in Python.

The Python you gave doesn't solve the problem illustrated. Here's the real solution. It's a new Python 2.3 feature.

Yeah, numpy rules. Not to name names, but I know some DoE labs use it quite a lot. It's very slick. So are many of the other python number crunching tools.

What if your CGI programs need to get data from libraries that only have C and C++ interfaces?

Python has really good interfacing with C/C++ code.

C is a low level language that nearly nobody understands....Java is a good high-level language.

When will the myth ever die? Java is not a high-level language. Neither is C nor C++. They are all categorized as low-level languages. Being high or low-level has nothing to do with how "good" a language is or how much hype or popularity or evangelism it has. Go study the theory of programming languages.

The level of a language has to do with the expressiveness of the paradigms (concepts) you can use directly in the language. In this regard it can be easily argued that C++ is of a higher-level than Java because it supports the programing paradigm of generics, whereas Java in it's current form does not. But then look at something like Python and it's many higher-level features such as dictionaries (associative arrays), generators, or even built-in infinite-precision numbers and imaginary numbers. In those cases the language allows you to directly express those complex concepts that you have to "program" yourself (or use libraries) using lower level languages. And then you can progress up to languages like Haskell and so forth which are higher-level still.

As another example, it should be obvious that within it's intended problem domain even a language like SQL is of a higher-level than Java, and SQL is still just of some intermediate level. Even some generally unpopular old languages have some high-level features not found in Java/C/C++ like Scheme's continuations or COBOL's PIC formatting or Fortran's matrix arithmetic. I know you can program those in Java, but those high-level concepts are not directly provided by Java.

In the big picture of all the languages out there Java is decidedly pretty far over on the scale of being low-level. Again level is not a scale of goodness, so don't fall into that misconception and use that term as such.