Python vs all the major professional languages

Question

I've been reading up a lot lately on comparisons between Python and a bunch of the more traditional professional languages - C, C++, Java, etc, mainly trying to find out if its as good as those would be for my own purposes. I can't get this thought out of my head that it isn't good for 'real' programming tasks beyond automation and macros.

Anyway, the general idea I got from about two hundred forum threads and blog posts is that for general, non-professional-level progs, scripts, and apps, and as long as it's a single programmer (you) writing it, a given program can be written quicker and more efficiently with Python than it could be with pretty much any other language. But once its big enough to require multiple programmers or more complex than a regular person (read: non-professional) would have any business making, it pretty much becomes instantly inferior to a million other languages.

Is this idea more or less accurate?

(I'm learning Python for my first language and want to be able to make any small app that I want, but I plan on learning C eventually too, because I want to get into driver writing eventually. So I've been trying to research each ones strengths and weaknesses as much as I can.)

Anyway, thanks for any input

Answer 1

An open source project I work on for VCS integration (RabbitVCS) is written entirely in Python/PyGTK and includes:

• Two file browser extensions
• A text editor extension
• A backend VCS status cache running asynchronously, using DBUS for the interface
• A fairly comprehensive set of dialogs, including VCS log browsers, a repository browser and a merge wizard (maybe that one isn't such a selling point).

There's no standalone app, but we're thinking about it.

Because we're always adding new features, and currently trying to adapt to new VCS', Python is ideal for the ability to quickly refactor entire layers of code without breaking our mental flow. I've also found that the syntax itself makes a real difference with complicated merging of version controlled branches, but that might come with the ability to read it quickly.

Recently we've begun adding support for a new VCS, requiring:

• refactoring current code to separate VCS specific actions and information from common/generic information
• refactoring the UI layer to accomodate the new functionality

Most of what we've achieved has been possible because of the availability of C/Python bindings (eg. PySVN, Nautilus-Python, etc). But when it hasn't been available... well, it's not that hard to roll your own (as a developer did for the new VCS). When the bindings lack functionality... it's not that hard to add it.

The real drawbacks so far have been:

• Threading mishaps. Lesson learnt: forget about threads, use multiple processes where possible or your toolkit's threading method (eg. PyGTK, wxPython and Twisted all have their own ways of dealing with concurrency)
• (C) Extensions. Cause threading mishaps (they almost invariably lock the GIL, preventing threading). See above.
• Needing to hack on C bindings when certain functionality is unavailable.
• Profiling can be tricky when you're not just doing something based on a single function call.

If you want to know about more specific aspects, ask away in the comments :)