Python Moving into the Enterprise

Qa1 writes "Seems that Python is moving into the enterprise. At the recent PyCon it has become apparent that it's not just Google, GIS, Nokia or even Microsoft anymore. The article points out that Python is increasingly becoming a perfectly viable and even preferred choice for the enterprise. More and more companies are looking at Python as a good alternative to past favorites like Java. Will we finally be able to code for living in a language that's not painful? Exciting times!"

Comments

Jython?

[Crono]

Aren't some of them using Jython, which is really just Python on top of Java anyway.

Advantages?

[voss, sometimes...]

Im not a coder my self, altough I hahe programmed in Java and in python, but I fail to see Python's advantages comparing to Java in an enterprise environment.

Besides... wasn't Star Trek cancelled?

Re:Advantages?

[fyngyrz]

There's another advantage for me, not quite so obvious, that Python's indentation mechanism brings to the table.

I program a lot. In the course of my job, I have to review a lot of other people's code. I have a particular bracing style I use; and sure enough, I've not only become accustomed to it but also "tuned" to it to the point where it becomes difficult to read someone else's code if (for instance) they use the "K&R" style:

if (condition) {
....do_this_stuff();
}

Because at my company, code looks like this:

if (condition)
{
....do_this_stuff();
}

Those two styles lead to a considerable difference in code density, and so affect readability and my "tuned" response to what I see. And there are so many other C/Java coding styles re bracing and indentation, or lack thereof.

In Python, there is one indentation style. Just one. Not bunches of them. So I get used to the way Python looks, the "tuning" goes into my backbrain or wherever the heck that stuff lives, and I can read anyone's code. This is a distinct benefit for me, and I suspect for others as well.

I would have loved a C compiler that didn't use braces, but used indentation instead. Man, that would have been glorious. Sigh.

python performance

[khuber]

Python is a nice language, but it's excruciatingly slow. It's below Tcl on The Computer Language Shootout, which is telling.

Re:python performance

[Sweetshark]

If you feel you have better python code to perform a task on the benchmark, feel free to submit it.
Actually I tweaked around with the code - but the rule of the game are just wrong. Just look at the fibonacci test. It requires you to do the stuff completely recursively - thats one of the rules. So you not only generate a huge return stack, you also calculate all the fibonacci numbers far too often. This is just braindead. A good requirement would say: "Calculate the nth fibonacci number". A simple solution would be to start from the beginning and not recursively calulate every fibonacci number bazillion times.

Ok, the test description says that its task is to show the performance of recursion. But then they have to find a task where recursion is an merit - not a flaw. Otherwise you could claim your language is best because it has the best performing idle loops ....

Re:python performance

[zorander]

I agree with a lot of what you are saying, though it doesn't tend to stop me from using python.

If you want a language that's consistently unsurprising and surprisingly efficient, then try ruby. Performance is not a dream, but that's what compiled languages are for. It lacks most of python's inconsistencies and is really quite pleasant to work with. in ruby there are two sort methods, sort and sort!. One does it in place and one returns a new list. (the ! suffix for mutation and ? suffix for predicates is a gem. I'm pretty sure it was stolen from scheme. It really, really helps make your code clearer)

I still find python more practical for large projects, though, because of the large library and potential for rapid development. I generally use python (possibly with C underpinnings) for larger apps and ruby (with its perl heritage) for scripting. Blocks are the greates when you're dealing with ssh sessions, opening and closing files/database connections, etc. As for per,l I've generally avoided after a few bad experiences trying to decipher six month old code. I really don't think it has a place when ruby has most of its features and enough of it's syntax along with the slickest object system around short of smalltalk.

A quick check on Dice.com

[thammoud]

for Python jobs. It returned 312 jobs. Java returned 9196. I don't think Python will ever dent Java's dominance in the enterprise. Do you really expect Python to do what .NET has failed to do? Not a chance. It is a cute scripting language. No more and no less. Python competes with Perl and Ruby.

Kill the GIL (Global Interpreter Lock)

[hagbard5235]

I love python. It's by far my prefered language for development, but it has one major impediment that makes it very hard to take seriously in many rolls in an enterprise: the GIL (global interpreter lock).

You see Python has quite good support for threads, but there are a number of operations in the interpreter that are hacked into being thread safe by providing a global lock on the whole interpreter. One of them is reference counts on objects. So everytime I do an assignment, I have to queue for the GIL. This effectively means that I only really run one thread at a time, even if I have multiple CPUs in the box (or soon, multiple cores).

As more and more applications start shifting to multicpu (or multicore boxes) this problem becomes a much more noticable issue.

Kill the GIL.

Re:Too bad...

[masklinn]

Another poster already made a clarification on this. I didn't "mis-speak" I was just a bit obscure with my meaning. Point being, if you code in C/C++ you'll spend a lot of time making the program work correctly. If you write in eg Java or Python you can get the program working correctly in a fraction of the time. This means you can add polish or move on to new stuff. Point being, you are more productive in other languages as you don't have to mess with the details so much.

One of the very important features of Python (i don't know much about java as i hate that language, but i'd assume it's close even though it'd be tought to be better than Python in that field) is the ease of creating C/C++ modules/extensions to the language.

That's where i'll desagree with whateverparent who said that high level "so called scripting languages" should only be used for prototyping/testing and should be cast aside for final app:
It's well known that ~10% of an application's codebase consumes ~90% of the application's resource needs (source: my ass), high level modular languages with easy ASM/C/C++ integration such as Python therefore allow you to:

• Develop the whole application in a fraction of the time you'd need to develop C/C++ version
• Using it as a "proof of concept" of the app's viability
• Fully test both application and test-cases (including unit tests
• Identify performances "roadblocks" modules/parts
• Recode these modules in a more efficient language using the already perfect testing tools

You'll use maybe 10% of the "full C/C++ approach" coding time to code the initial java/python/ruby/whatever high-level language you prefer version, 5% or maybe 10% top to recode the performance-critical modules in low-level languages, and you'll get... 99% of the low level version performances for under 20% of the dev time (with less chances of memory leaks and better portability to boot)

The stupid part is that most people don't even realise the ease of embedding low level modules into modern high level languages, and therefore use a "all or nothing approach", either full high level or full low...
Learn how to use your tools guys, low level compiled and high level interpreted language do not oppose themselves, they're complementary and both are necessary to get the best out of your dev teams