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

Which Enterpise

[Anonymous Coward]

TOS or TNG?

Jython?

[Crono]

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

Re:Jython?

[pogofish]

The Jython language is still (essentially) an older version of Python. Just because it runs in a Java VM and can integrate with Java classes doesn't moot the point about doing enterprise work by "coding in a language that isn't painful."

Re:Jython?

[hey!]

I don't find Java as a language painful.

It's the output of Java programmers that turns my stomach.

Re:Jython?

[hey!]

Well, my point is that more knowledge isn't necessarily a good thing, if it isn't coupled with judgment -- wisdom if you will.

I think the level of knowledge among Java programmers is impressive, but by in large I've found they aren't necessarily better programmers because of it. I've learned this the hard way, by hiring people with incredibly impressive knowledge of Java APIs, and then watching them struggle with overengineered designs that attempt to drag as much of that knowledge in as they can manage. I'm not going to make sweeping generalizations here, only to state that I've had bad experiences Java guys who prefer to wander lost in the wonderfully rich world of Java APIs and frameworks than focusing on a customer's problem.

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?

[m50d]

http://netpub.cstudies.ubc.ca/oleary/images/python _java_comparison.gif may give you an idea. Quite simply it's easier to program in, and you're more productive using it.

Re:Advantages?

[aldoman]

I agree -- Python is fantastic for quickly building small apps, or even much larger ones.

The problem arises in Python's web programming support. The documentation is pretty much non-existent and you can soon get module-overload when you are importing more and more modules to do fairly simple stuff in web apps.

Sometimes I just think while Python is most certainly a far better designed language, PHP/ASP.NET (C#) seems much more 'pratical', and it's definitely much easier to quickly build web apps in.

Is there much effort to improve Python's web support? A manual with similar completion of php.net would help it go a lot lot further.

Re:Advantages?

[voss, sometimes...]

Good point, but bad example.
If you take out comments, which one is more easier to read?

I have nothing personal against Python, actually I can say that I am a fan of python, but let's use a right tool for a right job.

Re:Advantages?

[archeopterix]

Until you find out that you need to code most everything from scratch due to the lack of standardized libraries and frameworks, and you can throw the whole "productivity" argument out the window.

I'm curious about that, since my experience with Python is just the opposite - everything from http stack, unit testing framework to xml parsing is in the standard lib. Please name at least one area where Python standard library is lacking functionality.

Re:Advantages?

[NeoBeans]

Amsing site, but... it didn't answer the original question. It just shows a comparison of two "Hello World" programs.

The one thing that Java has going for it are "standard" APIs you can bank on. Is there a standard set of enterprise APIs for Python akin to J2EE?

And all of this isn't to say that one can't leverage both technologies where appropriate, even in commercial products...

Re:Advantages?

[BasilBrush]

If you haven't already, you want to get hold of a copy of
Foundations of Python Network Programming.

My only experience of web progamming in Python is the client end, for web-scraping scripts, and its great for that. The one problem I have is that once in every few hours urllib2 locks up whilst trying to get a page from a particular site.

Re:Advantages?

[rmccann]

A poor example. The java code is only longer because of all the braces. That example implies the only strength python has is lack of braces.

Re:Advantages?

[srid]

The one thing that Java has going for it are "standard" APIs you can bank on. Is there a standard set of enterprise APIs for Python akin to J2EE?

I am not trolling, but isn't the standard Java API painful to program with. Who wants to code 4-5 lines just for opening a file?

In any case, there is PEAK for Python.

Re:Advantages?

[platypus]

Really, try Zope.
Yes, it's a little bit of a learning courve, but (and I did all of them for a living) it be beats Java/Tomcat/Struts and PHP hands down in productivity/maintainability once you get a grip on it.

Re:Advantages?

[afd8856]

Do yourself a favor and sacrifice 3 months of your life learning Zope & Plone. If you're into web development, it will pay off big at the end.

It's like: why build your own search engine, security engine, your own membership system, html form engine, templating system, cache engine, skin system, content types & custom types, etc, when you can just use zope & plone and get a complete framework with open source products and addons on which thousands already develop at the highest profesional level?

I admit that Plone and zope suffer from some documentation problem, but it's possible to overcome that. There are free books, available online (Zope book and The Definitive Guide to Plone) that can get you through. The documentation on Plone.org is getting very good. There are several code repositories (collective is one of them and some on zope.org) that have example products. Also, read the sources, they're not that hard to understand.

And before any of you jump and shout Booo!! ZODB, let me remind you that you can use just as well a reqular sql server to store your content information.

Re:Advantages?

[Vengeance]

Yes, well, if your biggest problems with software development are an inability to deal with brackets or declare variables, you probably shouldn't be coding at all.

What a silly picture.

Re:Advantages?

[hey!]

Having used both, I'd say that Python is quite a bit terser than Java, which is very good in itself. Java is a bit pickier at compile time, which usually is a good thing.

Probably the biggest difference is that there are no checked exceptions in Python. Java has both checked exception and non-checked ("runtime") exceptions, but the normal type of exception used in practice is checked. A checked exception is compulsory for the caller to handle or to pass up.

In theory, a programmer using an API with checked exceptions has to consider all the things that could possibly go wrong. In reality, the idea you can catch every error before you get to testing is a pipe dream. You often don't know what you want to do with it until you have some empirical experience with your basic design. So you do one of two things -- either handle the exception in a half-assed but temporary manner (hoping you'll remember to come back and fix it later), or you pass the buck.

Since the best of these two alternative practices (passing the buck upward) is the better, that means that it is a lot of work to get traction -- you can create a facade layer to orchestrate all kinds of low level stuff, but there is a tendency for that low level stuff to bleed through your facade. Modern Java practice (within the last couple of years) has rediscoverd the runtime exception -- which works exactly like the Python exception. Hibernate 3, for example, uses runtime exceptions. Personally, I'll rip bleeding strips off flesh of one of my guys who does something stupid with an exception -- because it's so easy to just wrap it in a runtime exception (we have a wrapper class for this) and rethrow it. Throwing an exception in a tester's face leads to quicker fault discovery than papering it over.

I think the remaining difference between Python is that it's concept of collections are built-in, whereas the Java language only has generic objects and containers are built using this low level stuff. The resutl is that Python gets a big win when it comes to providing terse, convenient and easy to read syntax for processing all the elements in a collection. In programming terms, this task is about as common as dirt on a farm, and is a major win for Python.

I think Groovy may be more the way to go for Java shops looking for a productivity boost. Python has its own set of gotchas. Which is not to say it isn't quite good, but I'm not a big fan of the idea of combining Java and Python.

Re:Advantages?

[CrocketAndTubbs]

Its the package name for the class File. Similar to c++ namespaces. Its a CS thing dude.

That said, the grandparent poster was a bit disingenous. The File class is roughly equivalent to the stat function/structure in C. You can't read the file without creating an inputstream/reader.

So yes. You are correct. It is more verbose when doing simple operations. But I like to think that more complex operations fall together more easily.
Many programmers like to whip something out now. A quick "one off". Instead, often, with a little more time and more ground work, they can make something that is reusable.

In terms of the IO being verbose. Well its pretty flexible. 2 Interfaces (InputStream/OutputStream) are used for many different opertations. Read/write a file. Read/write to/from a socket. Read/write from a string or byte array. Read/write serialized object s to/from a file/socket/etc.... Its not just File IO. Its ALL IO. Long story short, that is why.

Re:Advantages?

[arevos]

How about encryption and security, SOAP, ORB, web services, directory services, messaging services? You know, all those things that distinguish large enterprise applications from normal business applications.

I do suppose if your definition of a good enterprise language is one with all such libraries included, then Python isn't a very good enterprise language. Of course, one could argue that the benefits of Python outweigh the disadvantages at having to download extra packages to handle SOAP, ORB etc.

The difference between Java and Python is similar to the difference between C# and Visual Basic.

I'm a little confused. Are you saying that Python is inferior to Java because Java comes with library X included, whilst with Python library X has to be downloaded separately?

Python is slower than Java and higher level than Java, but beyond that I can't say that there's too much separating Java and Python as languages. Personally, I find programming in Python more efficient, despite having more years experience with Java, but that may be just me.

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.

Good:

[TeleoMan]

Maybe it'll eat Archer's stupid little dog.

No such thing

[RicardoStaudt]

"Will we finally be able to code for living in a language that's not painful?"

Dude, programming for the enterprise without the pain is like the Passion of the Christ without the crucifiction... It's Impossible.
In that case, Perl should fit perfectly.

Re:No such thing

[AndroidCat]

"Programming is pain, anyone that says different is selling something."
- The Dread Programmer Roberts.

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]

The Computer Language Shootout is pretty useless - often there is a reference implementation in C and the task is to code the *same* algorithm in other language. This ignores the fact that there might be better ways to solve the problem in the other languages. Or in almost all languages. Just take a look at the fibonacci test - it a stupid useage of recursion, if your compiler doesnt optimize out all the duplication. Ok, that would be a nice feature, but it just shows "This language/compiler is good at optimizing bad written code".

Also you can make the shootout say almost anything, for example if you also calculate the code lines in and weight pidigits with a 4 multiplier, Python comes up as the best of the "serverside languages" (Perl, Python, Java, PHP ..)

Re:python performance

[The Famous Brett Wat]

I think that Python is supposed to be better in benchmarks not listed on that page, such as "mean time to correctly add a feature to unfamiliar code, written by someone who has since left the company".

Re:python performance

[arevos]

I've never had any problems with Python's speed. It's fast enough for web applications. It's fast enough to use GUI toolkits. It's even fast enough for simple OpenGL demos (a shameless plug, I know, but it seemed relevant).

If you come across a situation where Python is too slow for what you want to do, then Python can work happily enough with libraries programmed in C. If that's still not fast enough, then use a different language. But I suspect that for 95% of all programming tasks, Python is fast enough.

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

[Edward Faulkner]

Computers are cheap.

People are expensive.

Writing in powerful languages like Python makes your people more effective. And most enterprise apps are not CPU limited anyway.

Re:python performance

[arevos]

One can calculate the nth fibonacci number using Binet's formula, so that particular test would be of no use:

import math

def fibonacci(n):
phi = (1 + math.sqrt(5)) / 2.0
neg_phi = (1 - math.sqrt(5)) / 2.0
return int((math.pow(phi, n) - math.pow(neg_phi, n)) / math.sqrt(5))

But I do understand your point. Different languages have different ways of doing things. The most efficient algorith in C, for instance, may not directly translate to the most efficient algorithm in Python.

Re:python performance

[goombah99]

Yes python falls in this weird crack between a scripting language and a high performance programming language. combines the slowness of perl with the inconvnience of structured programming. Its too structured and takes too many steps to be a good scritping language and too slow to be a programming language.

That being said I am enjoying it. I recently found I was writing a perl program that became unweidly in its comlpexity and impossible to maintain. So I converted to python. My reason for doing so was the existience of a nice matlab packages that allowed me the ability to recycle matlab code and make nice graphs. The syntax in python is cleaner with lets me do more complex array manipulations in the scientific envirnoment.

On the other hand I note that this syntactic sugar is simply a coating. FOr example, python implementes obects via an underlying hash just the same way perl does. But it hides it from view. Thus you get less flexibility in objects than perl and no real ability to optimize their speed since the access method is frozen in the syntax.

other things that trouble me are its seeming incompleteness of many of its metafors. For example, variables do spring into existence upon assignment but they dont auto initialize. Thus simmple things like counting the occurence frequency words in a file becomes a hassle since you have to either explicitly initialize every hashkey value to zero, or use one of the slow accessor methods (like .get()) that introduce huge perofrmance penalties. And the method of doing this is different for arrays, hashes, and scalars. auto-instantiation is somewhat dangerous too since a typo can now become an error without some means of declaring a variable name was meant to exist (e.g. the perl "my" statement).

Related to the lack of auto-initialization is the tendency to rely on the crutch of throwing exception rather than returning default values or signals that allow the progammer to decide if it's worth throwing an exception. I find I end up wrapping too many inner loop clauses in "try" statements. If operations that failed simply returned "None" or zero as appros many things could be simplified without any loss of ability to use exceptions properly.

other incomplete features are a lack of consistency on when an intrinsic operation is done in-place or returns the result. for example .sort() is done in place while .ltrim() is not. While one might wish to argue that space issues can require in-place operations, it woul dbe better to detect when an operation can be done in place from the syntax: a = a.sort() should be done inplace. b = a.sort() should not modify "a".

typcasting also seems to be incomplete as well. Take for example the casting of strings to integers. try this: i= int(45.3); i = int('45') ; i = int('45.3'). The first two casts work. the last one is an error. Why? I note .atoi() also fails in the same way.

My final lament about unfinshed python is the screaming lack of a decent syntax chekcer. Too many of its errors occur at runtime. It's weird that its the low level syntax of python that seems so unbaked. The high level imports are luxurious indeed and are a major attraction of the language. Having a conveinent operation like "shelve" for persistence takes enormous pain out of coding (now if 'shelve' could just use objects rather than olny strings for keys it would be complete).

My hope is that someday python will take advantage of the syntactic sugar to imlpement objects in a faster way under the hood.

all in all I do like python because it's a lot simpler to get the job done than Java or C++. If you know perl then python is useless as a scrpting language (sadly pathetic really) but if you dont know perl then python must seem like a fantastic scripting language if you are coming from C++.

Re:python performance

[Bob9113]

And most enterprise apps are not CPU limited anyway.

Say what? You must be living in a very different world than I. If it's an enterprise app, then it has a few thousand internal users. Multiply a few seconds by a few thousand people by a few times an hour by a few dollars per hour. Performance matters. Middle of last year my company pulled two people off their primary project to add a feature that saved our primary users two mouse clicks. Those 4,000 users now save 3 seconds, 10 times an hour, 8 hours a day. It's like getting an extra 33 employees for free.

Now, I hasten to add that performance isn't the only thing - if it takes three extra months to add a new feature then you've got to multiply 3 months by all those people not doing what they could be doing with the new feature. But claiming it's a non-issue is shortsighted.

Re:python performance

[Waffle Iron]

My point was that we can understand more about the method from reading the Java declaration than from the Python declaration.

At the expense of having to write twice as much code, adding endless typecasts to your code, wading through endless documentation covering redundant overloads that handle different types, requiring a separate compile step, installing a VM that uses 10X the disk space and memory, and having only one available programming technique, OO, without other useful ideas from methodologies like functional programming.

Re:python performance

[platypus]

Those 4,000 users now save 3 seconds, 10 times an hour, 8 hours a day. It's like getting an extra 33 employees for free.

Did a consultant compute that number?

Re:python performance

[Wavicle]

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.

Can you establish that more fully? How is testing say, a recursive-descent parser, going to be a more valid test of recursion than a recursive solution for fibonacci numbers?

Fibonacci is convenient because you get lots of recursive calls while only hitting the stack, and no integer overflow. If you were to use a recursive parser and python ended up slower than the others, you could easily blame it on the non-recursive work you were doing. The fibonacci example allows you to accurately describe the recursive performance without all that other stuff getting in the way.

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.

Re:python performance

[Bob9113]

Clearly everyone missed my point, so I'll clarify.

I was using an example from the real world to point out why 3 seconds matters. In any significant application there will be some processes that are sufficiently complicated that the choice of algorithm or choice of language will lead to a 3 second delta one way or another. There will also be places where adding a UI shortcut will save 3 seconds.

The real world example talks about UI shortcuts that can save those 3 seconds, and Python makes it easier (according to the common wisdom) to add features. Other languages are more performance centric, and make it easy to save those 3 seconds in operation intensive sections of the code.

I wasn't arguing that Python is bad because it's not as performant. I was saying that both CPU performance and UI friendliness are important, so choosing between Python, Ruby, C#, Java, C++, C or any other language on the spectrum is a question of weighing values.

Ferfucksake people, stop trying to be argumentative and start trying to understand what people are saying. We all claim to be so smart, is our only ability with our intelligence to pick nits? Or can we use our intelligence to seek mutual understanding?

I mean, I can see why the media is turning into a bunch of ranting extremists - they're just a mirror reflecting our own horrible image.

Feh.

Microsoft's involved?

[The Amazing Fish Boy]

I don't know whether to be happy or afraid.

Re:Microsoft's involved?

[m50d]

Happy. It's open, and could be a sign that MS is actually "getting it". Besides, it's already possible to do python under java, but IronPython looks better, and MS is employing the guy who does it.

Did anyone else think...

[lxt]

...Monty Python was merging with Enterprise? Now there's a show I'd like to see... :)

Re:Did anyone else think...

[Stormwatch]

Yeah... to boldly say "ni!" where no knight had said "ni!" before!

Re:Did anyone else think...

[Spoing]

2. ...Monty Python was merging with Enterprise? Now there's a show I'd like to see...

"I wish to complain about this tribble what I purchased not half an hour ago from this very boutique." ...

Toolsets

[justanyone]

I work at an Application Service Provider startup with 16 employees (5 developers) using Python (30K lines+).

I have 6 years of Perl development plus another 8 in C. So, a newcomer to Python (about 2 months now), I have several reactions shaded by that experience:
* Nice syntax: Not perfect, but very passable overall.
* Love the no-brackets: Indentation as a means of delineating code blocks is great; there's no debate over where to put squiggly braces (the 'if test { statement; } stuff;
* Immature toolsets: there are very few mature toolsets yet. We're using SQLObject, which is in version 0.6, as an object-relational-mapper. It's got some limitations and is admittedly not 'enterprise ready'. it's hard to compare to the Perl DBI because the dbi just is an interface and doesn't do mapping.
* Lack of CPAN: the single most fantastic "tool" I've found in my programming career (15 years) has been CPAN. Got a problem? Someone has probably already seen it and started a solution. I know this is in the works for Python but the tools are not all there yet.
* Syntax (bad): Lack of a requirement to declare vars before use. I really would like the ability to require that all vars are explicitly declared before being assigned to. it would help coding reliability.

Just my 5 cents.
-- Kevin

Re:Toolsets

[Xrikcus]

You may not have arguments between programmers with indentation based delimitation. However it only takes one contributer to accidentally use tabs rather than spaces to indent, or vice versa, and the code can actually look fine but suddenly fail to execute correctly as the interpreter becomes unsure what the indentation levels are. Then of course how do you automate a fix? At least with bracketing one can run indent over the codebase to make it all consistent.

Re:Toolsets

[Ursus Maximus]

Kevin wrote:
Syntax (bad): Lack of a requirement to declare vars before use. I really would like the ability to require that all vars are explicitly declared before being assigned to. it would help coding reliability.

Actually, Guido von Rossum (the Creator of Python) is working on optional declaration of variables for a future version of Python. Although some Pythonistas are annoyed, it may give folks like you, Kevin, the best of both worlds. There is discussion on comp.lang.python about this from time to time, but it certainly appears as though Guido may take action soon;-))).

Ron Stephens
Python Learning Foundation
http://www.awaretek.com/plf.html

sigh... how about a real opinion?

[paRcat]

The first dozen replies are all trolls, so I'll add my experiences for posterity's sake.

I've been using python for pretty much anything in my company that isn't web based, and things couldn't be better. There's talk about python being slower, which it is, but most libraries that do important things are just C wrappers anyway, so the speed decrease is negligible as python is just holding the logic. Tk is nice enough, I guess, but I tend to use wxPython. Either way, it gives you cross platform GUIs, which is always a nice thing. Using pyexe allows you to even 'compile' scripts into exe files with win32 machines.

To be absolutely honest though, I can't think of an easier language to learn (I even teach >40 yo women now and then!) or a quicker language to code in. Once you're accustomed to it, the code just flows out, and I've seldom been disappointed by the results. The formatting requirement helps to ensure that your code isn't a disgusting mess that no one can figure out, YMMV.

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.

Re:A quick check on Dice.com

[jimicus]

Had you done the same test 8 years ago but searched for Java versus C/C++, you'd probably have seen the exact same results.

Re:A quick check on Dice.com

[FidelCatsro]

Alot of us never thought PHP could make a Dent in perl , but it did.
if you had checked for python jobs just 2 years ago i would be amazed if you could find any .312 is a dent although a small one , and yes i do expect it to do what .Net has failed to do this as .NET has no real advantages over Java in the enterprise market , and the dependance on MS OSs is a real disadvantage in a market where Solaris etc still play a sizable part
(mono is not an option right now).
Python is able to run on all of these systems , Python has been proven over the years as a strong language and most importantly Python has the support of the OSS world which is becoming an increasingly large force in the industry .
So maybe right now python cant take over , but 5-10 years down the line you may just see a very difrent picture

Re:A quick check on Dice.com

[Liquidrage]

See my other post to the same parent. How can you say it hasn't dented it?

You can repeat the same ol' tired mantra, over and over, it doesn't make it true.

.Net is getting heavy use in the enterprise, and in this thread, has about 80% of the jobs that Java has advertised. Now personally, I don't think that's the best possibly way to determine use. But it is what is used in this thread. .NET is about 3 years old, Java's about 10. That's a dent.

And I'll even make the logical case showing how it is a *dent*, and not just a VB rollover (which I'm sure much of it is).

Apps, that due to scope and criticality, would never have been done in VB (mostly due to it's lack of support for true OO design) are getting done in .NET now. For certain apps, there really was no competition for Java. Now there is. And it comes down to a few criteria for the managers (experience of the current staff if any, what marketing smoke was blown up their ass and by who, what buzzwords their boss is big on at the moment, and if there's anyone actually technical in the decision making process that actually is able to point out the best tool for the task at hand, amongst others).

Also, it used to be split, you had MS goons writing ASP for web (with maybe some really crappy custom COM being a DAL, or some specialized functionality), VB for desktop. Now, it's all wrapped into one package, .NET

And it is being heavily used in Enterprise development.

Yes, but what about the GUI - speed no problem

[bblazer]

While I agree wholeheartedly that python is a wonderful language to code in, I think that it lacks a sting GUI system. Yes wxPython is cross-platform, but without getting overly detailed here, it definately lacks the detail and robustness of SWT or even Swing. Until wxPython can stand up to those, I think the movement to it for more broad based use with be a bit slow. As far as apeed goes, who cares? We are not programming for 286 machines anymore!

Re:Yes, but what about the GUI - speed no problem

[costas]

Agreed on wxPy, but you do know that SWT and Swing are scriptable from python thru Jython (or the Python-Java bridge project, forget the name right now)? IIRC there has also been an effort to wrap the native SWT widgets in python w/o going thru Java, which would be awesome.

But overall, I completely agree: the std python distro needs to standardize on wx, get rid of Tk and at least incorporate the win32all distribution in the win32 version (it just too nice to leave out).

My biggest peeve as a long-time pythonista (the newsbot in my sig is 25k+ LOC of pure Python) is the standard library: I can live w/o a CPAN-like repository (although that would rock), but for a language that used to boast that it comes "with batteries included" the std lib has gone downhill in the last few versions: too many overlapping or competing modules (why, why do we need httplib, httplib2 and urllib?? or getopt and optparse? and what are the differences between them?) and not enough attention into polishing the library into the fantastic toolkit that was around the 1.5 or early 2.1 series.

Someone, probably the BDFL, needs to stand up and take obsolete modules *out* of the standard library, so that the better ones can be improved even more, instead of having various tweaks and improvements going into overlapping modules. That's the point of having a *standard* library after all...

I'd rather have a good std lib than function decorators and other exotic language constructs...

Re:Yes, but what about the GUI - speed no problem

[qbwiz]

I wouldn't recommend taking modules out of the standard library, but merely marking them as deprecated and possibly removing their documentation from the new versions of python. That way, we won't break old programs, but we could prevent people from starting to use them.

Google is not enteprise?

[vidarlo]

It seems Google is using Python for a good deal of stuff... And I thought google was enteprise

Three barriers to enterprise Python

[blackhedd]

1) The twenty minute problem
Many programmers, including top ones like Eric Raymond http://www.linuxjournal.com/article/3882, are so put off by Python's use of whitespace as a block delimiter that they swear never to touch the language. In my case, this lasted for two years. You need to spend twenty minutes learning the language, after which the whitespace stops being a problem and starts looking like one of the many great ideas in the language. The challenge is getting people past their initial disgust enough to try it.
2) Misperceptions about typing
Many people think agile languages like Python and Ruby are not strongly typed and therefore present scalability problems and can't be used reliably by large teams. But Python and Ruby are strongly typed (unlike Perl)- you don't get type conversions you don't ask for. The real distinction is that the agile languages are dynamically typed rather than statically typed like Java/C++. To truly grasp the notions of "duck-typing" and lazy evaluation of types is as much a stretch as it was to "get" objects for those of us who were around 15 years ago- it's a basic change in how you think. You'll know when you're there, because you'll see in a flash that Java's static type declarations are not only redundant and painful, but they are also in themselves a key source of brittleness in large programs over time.
3) The youngsters' problem
This is probably the biggest barrier: university CS departments have become nothing but Java training courses. In trying to better prepare grads for actual careers, they have added a lot of basic business teaching, which is good. But they no longer bother to give students a real understanding of actual computer science, sticking instead to a cookbook approach using Java. So young people arrive in enterprise IT shops knowing nothing but Java and thinking they know everything, so they are not open to anything requiring a different intellectual approach.

Re:Three barriers to enterprise Python

[Bob9113]

2) Misperceptions about typing
Many people think agile languages like Python and Ruby are not strongly typed and therefore present scalability problems and can't be used reliably by large teams. But Python and Ruby are strongly typed (unlike Perl)- you don't get type conversions you don't ask for. The real distinction is that the agile languages are dynamically typed rather than statically typed like Java/C++. To truly grasp the notions of "duck-typing" and lazy evaluation of types is as much a stretch as it was to "get" objects for those of us who were around 15 years ago- it's a basic change in how you think. You'll know when you're there, because you'll see in a flash that Java's static type declarations are not only redundant and painful, but they are also in themselves a key source of brittleness in large programs over time.

The "unwanted type conversions" thing is a nice straw man, but it won't wash. The value of strictly typed languages is in compile time type checking. It's good to have languages that are not type checked, and it's good to have languages that are. The former is better with smaller groups, smaller programs, or more proficient developers. The latter is better with larger groups working on larger programs with more apprentices on the team. The former allows more flexibility and speed. The latter offers more imposed speed limits (and less car crashes).

Re:Three barriers to enterprise Python

[Peter La Casse]

The value of strictly typed languages is in compile time type checking. It's good to have languages that are not type checked, and it's good to have languages that are.

You appear to be confusing static vs dynamic type checking with strong vs weak type checking.

Static type checking occurs at compile time, whether or not the language is strongly or weakly typed. Dynamic type checking occurs at run time, regardless of whether or not the language is strongly or weakly typed.

Disagreement still exists about what constitutes strong vs weak typing; the extreme definition of strong typing is "type checking that prevents all type errors", while the corresponding definition of weak typing is "type checking that does not prevent all type errors". I call this an extreme definition because it makes strong typing so rare that the term becomes less useful.

I think that the terms strong vs weak typing are best used when comparing two languages, so you'd say e.g. "compared to C, Python has strong typing". This contrasts with static vs dynamic typing, which don't need comparison to be valid: C is statically typed, regardless of what the status of Python is.

Re:Too bad...

[zootm]

"Processors are cheap." and "Disk space is cheap." are horrendous excuses for bad programming. If you have used these expressions to justify your application, you are a bad programmer!

"Bad programming" has many points to it. I'd include using an old-fashioned language like C or C++ in a system which does not require huge speed or efficiency (which is almost everything these days). It increases the development time of a project, increases the code complexity, increases the chances of runtime bugs, and increases the potential severity of what bugs you do have.

I'm sorry, but the "but it's slow" argument does not hold for most software designed today. Let's please get over it.

We will start to see alot more of it..

[codepunk]

Soon as the qt windows free version starts shipping I think we will see alot of renewed development of gui stuff in python. Currently wxwindows exists but it is a little funky to program in if you ask me. A good industrial strength redily available qt is going to move alot of things.

It is a great language we use it for everything, web services, linux / win integration, nt services, automation etc.

Re:We will start to see alot more of it..

[broward]

The rate of growth in python exceeds the other major scripting languages.

http://www.realmeme.com/miner/java.php?startup=/mi ner/java/scriptinglanguagesDejanews.png

Python is the only one that has a clear increase in rate of change.

How not to win the corporate mind.

[NeoBeans]

Take a look at the documentation for PEAK here. Now, take a look at the documentation for J2EE courtesy of Sun (API docs, tutorials, and the specifications).

For good measure, let's look at the documentation from a J2EE vendor here.

While PEAK sounds intriguing, I'm not sure that major projects started by Fortune 100 globals will leverage a technology that lacks the level of documentation quality you can find in other products in that space.

I bring this up because documentation is often an indicator of the level of quality you can expect in terms of support. This is not to say PEAK is bad or poorly written, just that the supporting documentation and resources don't match those available for J2EE implementations.

Remember -- it isn't the best technology that wins, but the technology that is most accessible. In the case of enterprise APIs, even though PEAK may be easier and more scalable (and this is an excerpt from their page): But PEAK is different from J2EE: it's a single, free implementation of simpler API's based on an easier-to-use language that can nonetheless scale with better performance than J2EE. ...it will need some time and some nurturing in order to compete for mindshare with developers and non-technical decision makers.

Re:Python *is* painful

[justanyone]

Curly braces { } have always been a stylistic thorn in the side of C, C++, and now Java programmers. I'm sure other languages use them, too.

The old K&R style of doing:

if (test) {
expression;
}

versus:

if (test)
{
expression;
}

this is NASTY in the debates it causes and wars people fight over which is 'right' or 'easier'. For those who don't know, Python doesn't use braces, it uses any consistent indent, as in:

if (test)
expression

Very simple. Reduces line count by 1 or 2 and completely removes the religious debate about brace location. I really like this. There's enough problems debating what the code header/copyright/IDENTIFICATION DIVISION (grin) section's going to look like. "I like #####!" "No, I like #-------!!!", "You Suck!" "No, You Suck!" etc.

Don't knock the lack of braces until you try it. it really does make the code look cleaner.

--Kevin

Only a few tweaks needed

[Nelson]

I think that the database connectivity could be standardized a little more, perhaps with an ORM. It's not bad now but as a postgresql user, I'm not really happy, the "best" connector needs some janked up mx library, there are a few dead connectors. It seems like python.org could take this over or some kind of packager could.

Then the newer pythons allow you to import from a zip. That needs polish, there should be a standard way to package a whole app in a zip (just to make it harder to screw up the file distribution. Having a single unit that contains all the needed code is a huge positive; it's just that much harder to screw stuff up.

Then there are people working on compiler speed, really it isn't as bad as you might think from some of the benchmarks. It can use some improvment though and people are working on it.

Why is whitespace significance a good thing?

[OblongPlatypus]

One thing I've never been able to grasp is why Python proponents always mention the fact that whitespace is significant as a good thing. I guess it could be argued that at least it's not a bad thing, in which case it boils down to a matter of personal taste, but everyone seems to be saying it makes reading unfamiliar Python code so much easier.

Well, with any other language, if I get a piece of unfamiliar code and have problems reading it due to weird indentation, I just run it through Emacs' indent-region. Can anyone explain to me why this is not just as viable as mandating the indentation policy by embedding it in the language's syntax?

Re:Why is whitespace significance a good thing?

[arevos]

I find it reduces clutter in my code. For instance:

if (x == 2) {
printf("Blah blah");
}

As opposed to:

if x == 2:
print "Blah blah"

The question is not so much why one should have a language with whitespace significance, but why one should not. Since the vast majority of well-written programs use whitespacing in this manner already, it makes some sense to do away with braces and semi-colons when they're not really needed.

Re:Why is whitespace significance a good thing?

[krumms]

One thing I've never been able to grasp is why Python proponents always mention the fact that whitespace is significant as a good thing.

Whitespace (or more specifically, indentation) significance forces you to make the visual structure of your code match its semantic structure.

Re:Why is whitespace significance a good thing?

[Berfert]

My issue with using indentation as a block delimiter is in the time it takes to do it. When programming in Tcl (my language of choice), I just hit tab and the code is indented to where it should be. If I add an open or close curly, the indentation knows where to go next (in order to be the most readable to me). How do Python programmers handle having to indent every line? I assume tab will (generaly) indent to whereever you were last indented to. Do you need to backspace/space mutliple times each time you switch to a new block level?

Re:Why is whitespace significance a good thing?

[Trifthen]

No, actually... it doesn't. I've seen python code that uses *only* the indentation rule - there was no other extra whitespace or comments anywhere. Not between functions, not between class declarations, not between loops, nowhere. Not only was this code unreadable, but it proved to me that you can't make someone a good programmer by enforcing semantic rules in the language. While we're at it, why not build a language that enforces javadoc-style comments at a rate of 40% or more to code? How about one that enforces a standard naming scheme on variables?

Personally, my code usually has a giant comment at the top describing the purpose of a class/library, a reference implementation, and version information. Before any significant chunk, I write out what I'm doing, and why - in case I ever have to read it again in the future. in the end, my code is probably half comments. This is good programming practice in general, and so few people do it that it makes me want to cry. Anybody, and I mean anybody, can pick up some of my code and figure out what's going on.

*That* is why I think python's enforcement of whitespace is a pointless anachronism. Good programming is good programming. Remember when Java said making everything an object meant everyone had to use objects properly? No, it meant old functional programmers would make a huge class, call it "UtilitiyClass" and use it like a library. You simply can not make good programming practice magically appear via language rules.

So yeah. I'll continue to roll my eyes when people mention python. No single attribute transforms an otherwise commonplace language into greathood. It's just another tool to me, with a weird limitation I could care less about, since it never applied to me anyway. Yeah, my code style would work in python; it also works in ada, c/c++, java, perl, php, and every other language I've used.

Python's cross-platform compatibility and somewhat extensive library are another point entirely. Why not push those elements instead? They actually mean something to good programmers who wouldn't give two figs about python's Awsome Whitespace Rule(tm).

Re:Python *is* painful

[Fragmented_Datagram]

Well, these guys do...

Whitespace

Java / Python / Ruby

[linuxbaby]

This article confirms it...

• Ruby is the new Python
• Python is the new Java
• Java is the new COBOL

:-)
(found many places online...)

Re:Too bad...

[Hast]

The same goes for poorly written C++ programs. Sure they may be a bit more responsive at times than a poorly written application in Java or Python but OTOH it has a lot more maintenence issues and the potential severity of the bugs are higher (ie buffer overflow vulnerabilities).

When I code for fun I seldom do that in C/C++ anymore. At least not I know that the application won't need "that extra juice". What's the point in spending several times the develeopment effort on making it work properly instead of adding polish or just doing new stuff?

No CPAN == GOOD

[Anonymous Coward]

Typical Example Mr. Golfplayer. Found a great little OSS application, needs compiling, uses Perl, running make, opps need to use CPAN, "Oh crap, company firewall blocks FTP", "No problem, I'll download the packages one at a time.", followed by individual downloads, packages added only to find out a package requires another package!

Bzzzt! Wrong!

Interdependencies of packages on CPAN are a clusterfuck. All the hack work is paid for by us compilers.

You tell me to make a backup of CPAN or what? You can't call these packages easily, it's crap work you have to make a offline mirror of CPAN. No. No. No. CPAN is the plague. You customize your Perl env and build and start using non-standard hack libs just because you can and you quote CPAN!

Python might not have so many libraries OR a so-called package repository but the standard libraries accomplish as much as the fancy CPAN calling Perl code.

Re:No CPAN.

[rakanishu]

Call me when Python has CPAN's 7848 modules. Then we can talk about "productivity".

I hear this over and over, but I have to wonder what percentage of CPAN's 7848 modules are actually used? Which ones have been replaced by better ones?

Python has PYPI which is growing. Python also comes with a pile of standard modules. I'll admit something closer to CPAN would be helpful. On the other hand, I haven't had any issues finding modules. Sometimes all you need to do is google or ask on one of the python lists.

Re:Too bad...

[FreeLinux]

What's the point in spending several times the develeopment effort on making it work properly instead of adding polish or just doing new stuff?

What's the point of making it work properly?!?!? Surely you have mis-spoken here.

Let's play a game. Let's suppose a bunch of little apps for which speed is not a critical factor for any one of them. As a forinstance, look at all those apps presently running in the system tray. Let's suppose that those apps are written badly or are written in inefficient languages. That shouldn't be too much of a stretch.

Now, let's try to do something. Whether you are trying to run a realtime application like desktop video conferencing or create a document in a word processor, it doesn't really matter. What ever it is that you try will be a struggle because the system's resources (CPU cycles, memory, swap space) are consumed by all those "noncritical" apps and their inefficiencies. A 1Ghz processor with 1 gig of RAM is no longer adequate? That's ridiculous! And yet, that is where we are at today.

Everyone seems to feel that their "Ultimate MP3 player" is the only app in the world or at least the only one that will ever be run on a machine. They don't think that speed and size are important. After all, they have a very powerful machine at their disposal with oodles of available resources, right?. They fail to realize that their program, no matter how wonderful, is only one of countless others that are all running at the same time and are required to share the resources. They fail to realize that their app may not be too slow when run by itself but, it becomes too slow when run with everything else.

Today, the preferred system is 3Ghz, 64bit, with at least 2 gigs of RAM. Why? What's the point of such a powerful system? Speed! That's the point. Speed is important. Code efficiency is important. But, as programmers continue to deny this and produce poorly written and bloated/slow apps or use inefficient languages, the time will come when a 6Ghz processor is not enough. Doesn't that sound stupid?

The trouble with parrots

[CoderDevo]

Dr. McCoy - - Captain, I wish to register a complaint... Hello? Miss?
Capt. Kirk - - What do you mean, miss?
Dr. McCoy - - Sorry Captain, I have a cold. I wish to make a complaint.
Capt. Kirk - - Not now Bones, we're closing for launch.
Dr. McCoy - - Never mind that, I wish to make a complaint about this tribble that I purchased not half an hour ago from this very bridge.
Capt. Kirk - - Oh yes, the Bajoran Blue. What's wrong with it?
Dr. McCoy - - I'll tell you what's wrong with it. It's dead, Jim, that's what wrong with it.

Re:Recursion

[colinrichardday]

The nth Fibonacci number:

Let a be the sum of 1 plus the square root of 5, all divided by 2. Let b be the difference of 1 minus the square root of 5, all divided by 2. The nth Fibonacci number is a to the nth power minus b to the nth power, all divided by the square root of 5. Should be in any text on number theory.

So yes, one can calculate Fibonacci numbers nonrecursively.

Python still has severe limits

[Cajal]

I'm a big fan of Python. I used it almost exclusively before taking my current job. But let's be honest, Python and Java just aren't intended for the same type of applications.

Python's standard library just doesn't have the breadth of Java's. For small apps, the CPython VM is lighter than Sun's JVM, but CPython's VM is lacking several capabilities that I'd consider pretty essential -- chief among them is the ability to return unused memory back to the OS. And for many tasks, CPython is still effectively single-threaded due to its global interpreter lock. Java has never suffered from either of these problems. These aren't trivial issues or the result of nitpicking -- they're rather severe limits (which make me seriously question the suitably of Python for enterprise apps, eg. Zope). Of course, once CPython does get decent threading, it's likely that it's GC subsystem will need to be totally rewritten. I apologize if it sounds like I'm beating up on Python. That's not my intent here. I love Python, and I only wish I could stop more people from using Perl :)

In fairness, it does look like the Python community is trying to address some of these problems. I just read a paper presented last week at PyCon 2005 on CPython's memory management. The author is developing some patches to let CPython return unused memory to the OS for most object types (except for Number, List and Dictionary). The memory manager still can't defragment its heap, so this isn't a perfect solution. As of a few weeks ago it looks like these patches haven't yet been accepted.

Re:Python still has severe limits

[DylanQuixote]

I've always be told that in C, free() doesn't (usually) return the memory to the operating system.
The memory is only available to other programs after the program exits.

As a result of this, most daemons will re-exec themselves to free up memory for the rest of the system.

At least, that's what I've always heard. Maybe newer versions of the linux kernel are much smarter...

Re:Toenails

[CatGrep]

Whitespace-delimited blocks are not the reason to use Python. Dynamic typing is.

Ruby will give you dynamic typing without all of the whitespace issues. Given that the two languages compete in (mostly) the same space, why should I go with Python if I don't like it's whitespace issues?

I've seen many cases where thirty minutes of practice gets rid of the problems people have with the whitespace.

But why do I have to adapt to the tool as opposed to the other way around?

Your reaction is just as the OP predicted.

The truth is that whitepace-delimited blocks can be a source of difficult-to-find bugs. It also makes it quite difficult to easily copy n paste code from one place to another. Add to this that it makes Python a very poor language for templating (embedding in HTML for example) and you start to understand why Ruby on Rails is doing so well.

Re:Better Python-GIS example

[Bazman]

Oops:

I meant OpenEV on sourceforge.net

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

[ArbitraryConstant]

""Processors are cheap." and "Disk space is cheap." are horrendous excuses for bad programming. If you have used these expressions to justify your application, you are a bad programmer!"

Okay, I'm going to refute this is two stages because you're wrong in two ways.

First, it's not a matter of "processors are cheap". It's "processors are cheap compared to programmers, sometimes". If they're paying for months of your time, most of the time it's way cheaper for them to get a faster computer than have you write the thing in a language that will take longer. That is of course dependant on the number of computers it will run on and the performance requirements of the project.

Second, Java and Python are not necessarily slow. In the case of Java, it's usually a matter of keeping heap allocations to a minimum. In the case of Python, it's usually a matter of spending as much time as possible in a C library (even if that means you have to write the C library).

Doing that will usually get you within a factor of two of the performance of C.

Available libraries

[quantum bit]

I really like Python. It's an incredibly powerful language -- what other languages give you the power to redefine what "is" means? For example, you can override the '.' operator (and getattr) and create whole sets of virtual objects that don't really exist. Things like object proxies for RPC or external resources like Zope become possible.

Its main two faults in my mind are:

1. Speed (but this is being worked on, see the Parrot JIT compiler)
2. Memory usage. wxPython especially is an excellent toolkit but a memory HOG.

As far as Java goes, I don't particularly like Java all that much, but one area where it has a definite advantage over Python at the moment is libraries. Not just the standard library, but what add-on libraries are available. Python has a lot, but Java has pretty much everything and the kitchen sink.

For example, I recently worked on a project that needed to display and manipulate SVG graphics. The two requirements are that it be cross-platform, and be done quickly (in just a couple weeks). I originally wanted to use Python but was unable to find a cross-platform SVG rendering library for Python. I came across the Apache Batik toolkit for Java and found that it was exactly what I needed.

Batik is pretty sweet -- you get a swing component that you can plop into an app in about 10 lines of code and boom -- you have one of the most compliant SVG renderers that I've seen to date. Plus it even gives you a DOM interface that will update the graphical view in real-time. As much as I dislike Java in general (even more bloated than Python :), the third-party libraries certainly made this project a breeze.

Re:Too bad...

[Anonymous Coward]

I'm sorry, but the "but it's slow" argument does not hold for most software designed today.

What planet are you from? I do a lot of work at oil companies and utilities, and they have tons of slow software that causes them to hemorrhage man-hours at an insane rate. I'm talking about the big name companies spending tens of millions of dollars per year on bloated applications that take 30-60 seconds just to start up and take just as long to perform many of their routine functions. People often use these various functions throughout the day, running them hundreds of times. This amounts to several hours per day of users twiddling their thumbs waiting for slow software.

Very often, there are only one or two vendors supplying some niche market such as geological interpretation or pipeline facility management. So if you can write an application that takes half as long to perform certain commonly used functions, you've just saved your customer hundreds of thousands of dollars per year in lost productivity, and they will pay you for that.

There are numerous areas where performance does matter. It's not always the most important consideration, but it's certainly not irrelevant.

Re:Too bad...

[jaydonnell]

"A 1Ghz processor with 1 gig of RAM is no longer adequate? That's ridiculous! And yet, that is where we are at today."

1 gig of ram is no longer adequate??? I don't know what "noncritical" apps you use, but I have a AMD 2200 with 512 of ram. I run both XP and Suse on it and I very rarely use up the ram or cpu and I run lot's of python apps. I program python and php for a living.

Re:Too bad...

[QuantumFTL]

Today, the preferred system is 3Ghz, 64bit, with at least 2 gigs of RAM. Why? What's the point of such a powerful system? Speed! That's the point. Speed is important. Code efficiency is important. But, as programmers continue to deny this and produce poorly written and bloated/slow apps or use inefficient languages, the time will come when a 6Ghz processor is not enough. Doesn't that sound stupid?

If there was money to be made by making that WeatherThing or UltimateMP3 player fast and efficient - companies would do that. There's plenty of programmers out there capable of writing in or learning more low level languages - of optimizing each loop or branch. The problem is that people are not willing to pay all of the extra associated with the development and testing of software written with risky optimizations (optimizations tend to complicate and obfuscate code, reduce abstraction, etc) in unsafe languages.

The truth is the consumer would rather spend an extra $100 to get enough RAM then spend $10 per program on their PC (that adds up faster) for the programmers to program it "correctly." It's not economically efficient, at least not in the eyes of the consumers.

Why do you think so many kitchen appliances last only a year or two nowaways? Or current VCRs which almost qualify as "disposable." People are rarely willing to pay extra when they think the low cost option is "good enough." In some ways this is what killed the Mac - it was better according to many metrics, but PCs were "good enough" for the average consumer, and the price difference wasn't justifyable.

A computer is a tool to get work done, nothing more. If people valued security, reliability, and efficiency enough, most software would be secure, reliable and efficeint. But people value features and low price, so that's what the market gives them.

Look on the bright side - at least compilers are getting better.

agreed--cleanup needed

[idlake]

The profusion of library modules with overlapping functionality is a real concern. The confusion over a standard window system (wxPython, Tk, ...) is actually just another example of that.

The sys/os split, logical as it may seem to the experienced Python programmer, also confuses Python newbies, as does the fact that string needs to be imported and that re is yet another separate module.

I think Python would do well with a major library cleanup, removing rarely used and duplicated functionality, and improving the quality of the library code that is there.

Furthermore, I think it would help for common string, I/O, OS, and regular expression functionality to be importable either via a single import statement (without name conflicts), or to be simply present in the default namespace.

Re:Python *is* painful

[rbarreira]

If I read another comment talking about the fucking lack of braces I'm going to punch the monitor... Why are people giving that so much weight instead of discussing the features of the languages instead?

And who cares about the programmers discussing brace placing styles? They'll surely find other things to discuss about with Python...

Re:Too bad...

[Hast]

What's the point of making it work properly?!?!? Surely you have mis-spoken here.

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.

Whether you are trying to run a realtime application like desktop video conferencing or create a document in a word processor, it doesn't really matter. What ever it is that you try will be a struggle because the system's resources (CPU cycles, memory, swap space) are consumed by all those "noncritical" apps and their inefficiencies

First off, I'm willing to bet that virtually none of the little apps you currently have running are written in Java/Python whatnot. A sloppy coder can leak memeory in any language. (In fact I'd say it's a lot easier to leak memory in a language without a GC.) So moving to C/C++ doesn't really fix the memory issue.

That they consume enourmous amounts of CPU is also not really true. Those processes I have running on my machine all go in at 0% CPU time. If you add them together they might reach a few percent. Not really something which will stop you from typing in Word.

The fix for this "problem" is to get an OS with a descent scheduler so you can prioritise processes properly. That way your real-time applications won't suffer because your little application wants to check for new mail.

What's the point of such a powerful system? Speed! That's the point. Speed is important.

No, bragging to your friends that you can get 180 FPS in Doom3 is important. Very few people actually need a 3GHz 64-bit CPU with 2GB memory, I have one and I sure as hell don't need it.

And while code has become more bloated and unoptimised by the years a lot of that is because today a computer can do quite a hell of a lot more than say 10 years ago. Is all of that necessary stuff? Hell no! Is it more fun? Hell yes!

Finally there is one specific area of consumer software that actually demands better computers. That is games. Interestingly enough that area also have many of the best coders.

Re:Great... but PLEASE allow 'implicit none'!

[Homburg]

Strictly, python doesn't allow variables to be _used_ implicitly, it only allows them to be created on assignment. But I agree that this can be a source of bugs (although in my experience much less frequently than giving variable an implicit value, as PHP - that terribly combination of the worst features of C and Perl - does).

Re:Received wisdom

[Daniel]

That's true, but regardless, this isn't a new issue. I also doubt that it has as much importance as some people think -- I hate writing large programs in dynamically typed languages, but I nonetheless find myself doing a lot of coding in them because of the other features that few statically-typed languages support, like (in rough order of importance):

• Reliable, portable, free implementations
  
• Automatic memory management
  
• Large standard and third-party code libraries
  
• First-class functions
  
• Built-in collection types (growable arrays and dictionaries)
  
• Sensible module handling
  
• Streamlined syntax
  
• Macros
  

Most statically typed languages miss out on one or more of these, and all of them have a much more dramatic impact on how quickly I can get anything done in the language than the lack of static typing does -- static typing doesn't get really useful until you have a big interconnected system (and of course the above properties help keep the size of your own program down by eliminating lots of).

I may spend a lot of time cursing at the lack of static typing, but the fact is that the inconvenience of missing the above features is enough to keep me using Python et al. The most annoying thing is that none of them are particularly tied to dynamic typing, except in the sense that it's simpler to implement a dynamically typed language, because there's a lot of theory involved in type systems (especially if you want to do any sort of inference).

Daniel

Re:Too bad...

[Money for Nothin']

If only more geeks considered the economics of what they're doing, as you have...

The logical extreme of the "all apps must be as fast as possible" argument is to code in ASM. I suggest that anybody who pushes this argument write every app in ASM. See how long it takes before this person gets fired for inefficiency...

Why are some coders hesitant to "use the right tool for the job"? ASM might be necessary if you're optimizing a crypto or compression loop, while C or C++ might be more appropriate for the rest of the app, but Perl or PHP are surely more-appropriate languages for web-scripting! Duh.

But no, we have these "code everything in C, C is the be-all end-all of languages" dolts... :(

Re:Too bad...

[jgrahn]

"Bad programming" has many points to it. I'd include using an old-fashioned language like C or C++ in a system which does not require huge speed or efficiency (which is almost everything these days). It increases the development time of a project, increases the code complexity, increases the chances of runtime bugs, and increases the potential severity of what bugs you do have.

C may be old-fashioned, but please don't lump C++ in with it. Chances are you haven't even seen modern C++ source code, which in practice has little to do with C source other than that you can link to C libraries easily.

That said, I'm all for programming in higher-order languages (e.g. Python) and I prefer to do so, but some problems are better solved in C++ or even C. It doesn't even have to be about efficiency; things like static type checking can be essential in large programs when it's hard to test all code paths.

hmmm

[Anonymous Coward]

There are a lot of things wrong with what you are saying. It looks like while you learned the language, you have a lot of trouble adapting to some of the "paradigms".

Asking for functions to return None instead of raising exceptions on errors ruins a fundamental concept of "focus on what the program should do" which makes exceptions useful. A significant percentage of C code is "if - else" statements dealing with such return codes.

In C or Perl, writing a file is a painful operation, along these lines:

open file for writing()
if open failed {
handle error
} else {
while not finished {
retvalue = write content to file
if retvalue not good {
handle error
}
}
close file
if close failed {
handle error
}
}

Note how inline error checking not only makes the bulk of the code, but also makes it less obvious what the code does. In Python, you'd do something along these lines:

try:
open file for writing
while not finished:
write to file
close file

except open failed or write failed or close failed:
handle error

That is even assuming we want to handle the error and not let it propagate up, which is made possible by the exception mechanism, and would be made difficult if all those functions would return on error.

Re:Too bad...

[fyngyrz]

Once you've fixed the gazillion-th bug caused by dangling pointers or out of bounds access you start to realize that...

...you're a really bad programmer and someone should teach you a few things, like how to manage resources.

I program in C every day and I haven't coded an error of the type you describe in over a year. I would know if I had -- our C memory manager catches all manner of pointer problems, accounts for all memory allocation and freeing, memory over- and under-runs, gives us stats on memory allocations and so on.

I'm definitely a Python fan, but your agument against C isn't valid. It's just an argument that crummy programmers write crummy C programs, which is not news.

Python is a perfectly reasonable language for coding certain types of applications, and it is also a good language for programmers that aren't that skilled because it puts a strong safety net in place for many types of errors with the exception system it uses. C is something else entirely.

Not perfect but good for many things

[ibm1130]

Last week I realised I needed some way of generating a bunch of stuff on the fly as prep work for a current project.
It had been mentioned in my hearing that Python was acceptable within the constraints for the overall program.
Figuring it was at least worth a look, I spent a day playing with Python basically putting together the things I needed to to do the task. In spite of a couple of disruptions, my code was fully functional and more or less ready for primetime by COB Friday.
I wouldn't use it for the real-time parts of what I'm doing if only because the framework being used is suitable as it stands ( C++/C/FORTRAN ) but for most other things it rocks.
I plan to push for making Python the standard glue language at the office.

Re:Too bad...

[globalar]

"Speed is important"

...just like price, just like quality.

You meet the demands of the project/customer. I'm not really arguing with you, but this is sort of the point of a thread about Python. It's a tool that helps balance this process for the developer - this in turn should result in benefits to the enduser.

It is nice to have a perfect balance, but efficiency is relative and (developer) resources are finite. Always.

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

Re:Whoa, this is all crazyness.

[Black Acid]

There's some validity to your point here. In this case, static typing signals you at compile time that you made a "stupid" mistake (ie, a mistake not caused by an improper understanding of the program requirements). But a dynamic language would signal the error just as quickly, because you'll get a clear, obvious error the first time your code runs.

Though the error may be clear and obvious, knowing it the first time the code runs can be too late. I've wrote code that can only run a few weeks every year (nothing important, but the nature of the program limited it to running only at very specific times), and Python has allowed numerous stupid bugs (typos, etc.) to stay dormant until I was able to run it. Static typing would have been very useful in this case.

Pychecker is a step in the right direction. It doesn't do very advanced type checking, but can warn you about inconsistant return types (returning a string in one path, but another data type in another, for example) at least. MJD's Strong Typing and Perl discusses how strong and static typing can be done right (in ML), in order to prevent many bugs at compile-time (in his case, infinite recursion). I hope we see more options for static typing in Python, if only as an option. I wouldn't want to not ever be able to write simple Python programs without declaring every variable, but for larger programs, static typing is definitely useful. Maybe in the future we'll see more languages that are able to prove that a program is correct (using static typing, etc).

Re:Purpose of dynamic types?

[Ambassador Kosh]

One of the benefits is in things like duck typing. Often you don't care what kind of object something is so long as it has some certain method. To put it in a practical way I work with zope which is a python based app server which has an object database as part of it. Often I will run queries and get objects back. Most of the time I don't care if it is a file, picture, dtml document, or any of the many other types in the db all I care is that it has an id and it is willing to draw its url. Those are the conditions I have for working with the object.

So you work with objects by interface rather then by type. The interface also does not have to be a complete interface. You can implement as much of the interface as you need for something. I have some objects that are not lists and can not be used as lists however I have implemented some methods that make it so you can iterate over them like lists and slice them like lists.

This makes many tasks far simpler and encourages more regularity in usage.

How do you check if a substring is in a string, an item in a sequence, a key in dictionary etc? How do you iterate over them? In python it is all the same. if substing in string, if item in seq, if key in dict and the for character in string, for item in seq, for key in dict, for line in file, etc etc etc.

Types are nice but the types the static compilers have are not the types my apps use. The static type systems just end up costing me more time to develop working apps with then the dynamic typing systems and you have to test the product anyways.

Re:Too bad...

[publius_ovidius]

Apologies in advance if I have misunderstood you, but ...

I think you may be missing an important point here. In older languages, you'll find that the bulk of the work was often thrust on the programmer because the programmer was far cheaper than the computer. One need look no further than the horror of JCL and COBOL to see a high level language that still required inordinate amounts of fiddling by the programmer to get it to play nicely with the computer.

Today, we find that the programmer is far more expensive relative to the computer. Simple economics dictates that shifting much of the load from the programmer to the programming language will save money. However, that's not the end of the story. Some applications need raw speed. Others do not. Choosing Python or Perl for device drivers or ray tracing is probably not a good idea. Choosing C or C++ for processing log files is also probably a bad idea (though not always.) An "always/never" dogmatic approach to language choice means that one cannot choose the best tool for the job, but is instead forced to twist every problem in such a way that your favored language is an appropriate solution (or, perhaps just as common, to simply ignore those areas where your favored language is a bad choice.)

In other words, don't be dogmatic. Dogmatism implies that you won't consider new ideas and that's almost always an error, even if the beliefs that you hold as true are true. Developer performance, processor performance and language performance are all factors that should be considered.

Re:Too bad...

[Ambassador Kosh]

You forgot a very important step. The VAST majority of the time those low level bottlenecks are also low level bottlenecks that other people have and there is already a highly optimized c module to do that task with a python binding already. So you just use that library and the problem is solved and you did not need to write any lower level code.

You are right though that a mix of high level and low level languages tends to give the best result in the lowest amount of time. What has shocked me is that from experience I have seen that pure c/c++ apps are almost always faster when redone in python even without anything outside the standard library. C/C++ show up very fast in these micro optimization benchmarks. However I have not seen them show up that fast on large codebases. Probably because it takes so much time and effort to optimize them. So while those apps could be made faster then the python versions it would cost too much money to do it since the code base is so large. This is an even better reason that that hybrid stuff pays off so well. The low level parts are so small that you can highly optimize them and you will end up with an app a good deal faster then ANY c/c++ app of reasonable since you can afford to produce.

Re:Perl is run by a Christian.

[the_greywolf]

i don't get you.

why? why does that matter? why should i care whether Alan Turing was gay? why does it matter what religion or faith Larry Wall may or may not follow?

Finding a good general purpose language is hard!

[Anonymous Brave Guy]

I do not like C++ as a language though. C's use can be justified for low-end systems, but C++ is in more of a quandary, since its architecture has been superceded by newer languages

The problem is that actually, it hasn't, although it surely should have been a long, long time ago. Alas, the bulk of the software development industry is so driven by marketing hype and buzzwords that it has collectively failed to develop a new language that is a serious choice as a general purpose programming language spanning many problem domains.

A lot of newer languages imitate C++'s approach in terms of design tools, most obviously Java, C# and now Visual basic.Net. However, the beauty is only skin-deep; these languages often lack the solid, underlying framework and reasoned design decisions that have gone into C++, with the result that most of the time they are lucky to be as good, never mind an improvement. The addition of generics to Java several years later is an obvious demonstration of what happens when you go for buzzwords and you meet someone who went for solid design principles.

Many other languages have something valuable to offer developers, but then go and spoil it in some other way, ultimately winding up with something that might fit certain niches, but isn't suitable for major development projects across a wide range of areas. Some common examples come immediately to mind:

Java Pro: emphasises safety, readability, and portability; con: sacrifices low-level control (and with it performance) and only supports a limited number of programming techniques, encouraging over-engineered, component-based designs Perl Pro: quick, flexible, useful for rapid development of useful tools; con: terrible scalability and unfriendly (to both programmers and tools) syntax restrict it almost exclusively to quick-and-dirty projects Haskell Pro: elegant and powerful syntax, serious support for powerful programming tools like higher-order functions; con: overly academic community, and puts purity above pragmatism, making it hard to use in real-world projects where things like UIs are involved

The list goes on, but the important point is that while each of these has good applications, they all have obvious flaws as well. Java is the closest to a serious general purpose language, but even today most of the serious Java code is restricted to server-side back-ends driving databases or some thinly disguised variant on that theme.

C++, for all its sins, remains a pragmatic, balanced choice for a general purpose language that can be effectively adapted to a diverse range of applications. Is it a perfect language? Of course not. It has gaping flaws in any number of areas. The problem is that no-one has yet produced an alternative that beats it on all of them without significant compensating weaknesses.

Re:Finding a good general purpose language is hard

[zootm]

I'm not convinced that Java, as an example, is a worse general choice than C++ (I'd assert that as often, or more often, than C++ is a good choice, Java would be a good choice, but that's obviously not really fairly decidable). You're right that everything has pros and cons, I just feel that C++'s cons began to outweigh its pros a while back, and it just seems more evident today.

I'm also extremely unconvinced that any of the languages you mention have less "reasoned design decisions" than C++. The advantage of these newer languages is that their programming is, in general, more "safe" than predecessors like C++ -- although none of them are a true "general" language (what is?), a competent coder should be able to pick up the one most suited to his or her project and use it, without fear of having to learn a whole load of coding rules to avoid buffer overruns and the like.

Although C++ can be a reasoned choice sometimes, I do not see it as useful for new projects in a lot of areas. For most purposes, there's a better choice. But that's simply my opinion, of course.

Python on the NX-01

[D4C5CE]

Then again, shouldn't we all be truly worried for Porthos?

Re:Finding a good general purpose language is hard

[Anonymous Brave Guy]

You're right that everything has pros and cons, I just feel that C++'s cons began to outweigh its pros a while back, and it just seems more evident today.

It all depends on your application domain. For applications that are predominantly UI/database driven, as obviously many are, C++ has few advantages over something like Java. However, in anything scientific (where performance is often paramount) or in huge markets like embedded or instrument-control applications (where tight code and/or low-level control are often required), languages like C and C++ are still far ahead of the competition IME. Java is making some inroads into the embedded space, but it's barely a blip in the graph right now.

I'm also extremely unconvinced that any of the languages you mention have less "reasoned design decisions" than C++.

I think that's a little harsh. If there's one thing you can fairly say about C++, it's that Stroustrup and the standards committee take their time and try to reach good, practical decisions. It takes forever to make changes as a result, but with a few exceptions (the designed-by-committee string functionality, for example) the underlying design decisions of C++ are really very robust. Stroustrup's oft-cited book, The Design and Evolution of C++, provides some fascinating insights into how a serious computer scientist designs a language, and the factors that weigh into that decision. Even where I disagree with a decision that's been made, not that that often happens with this particular programming language, I can at least understand the rationale behind the decision.

Compare this with Java's almost amateur development process, and the design weaknesses that have resulted. For ages, the Powers That Be dictated that generics/templates/whatever weren't useful, and wouldn't be included. Lo and behold, a few years later, they concede that they were wrong and retrofit them (but still in a feeble way that misses half the point and 90% of the power). More seriously, although Java has a vast standard library, much of it is a joke compared to the high-quality, often peer-reviewed work found in things like Boost, CPAN, and so on. For example, AWT was so bad they had to invent Swing, and that's still not a patch on serious GUI libraries like Qt or wxWidgets in their various forms.

In fairness, the less formal processes (a.k.a. benevolent dictatorships in most cases) that underlie many scripting languages (notably Perl and Python in relation to the current discussion) tend to be rather more flexible. Even so, how can a language that doesn't even have a specifcation apart from a compiler that its own author couldn't rewrite from scratch possibly be considered to have an industrial-strength design process? (That would be Perl, and indeed the reason for all the completely rewritten underlying mechanics for Perl 6.)

The advantage of these newer languages is that their programming is, in general, more "safe" than predecessors like C++

That is indeed a compelling advantage. C++ has always been written for "good programmers", the craftsmen who take their craft seriously enough to learn the details and avoid the obvious mistakes. Unfortunately most programmers aren't like that, and most companies are going to be employing "most programmers" most of the time. It is therefore a sensible management decision to go with technology that mitigates "most programmer" errors.

The only problem is that sometimes, you actually need finer control (and to accept the attendant risks) in order to get a good result, and if you need to hire some geeks to use that control, so be it. If you have a language that actually won't let them bend or even outright break the rules when they know damn well that it is safe to break them in the particular circumstances they're working under, then that's a serious liability to some kinds of project. If you're going to fall back on linking to C functions, using JNI, or whatever every time you need performance, you might as well write in a language like C++ in the first place, and just hire enough good people to write safe, high-performance wrappers for the low-level code...

seriously mistaken information. try is 24x slower

[goombah99]

I just tried your suggestion of using the try/except format. You are seriously mistaken if you think that is fast:

I benched the two pieces of code: (note the slashdot ecode tag removes the proper indentation, but this should be obvious in context)

#!/usr/bin/python
a ={}
c = 10000
for i in xrange(c*10):
b = i%c
a[i] = 1+a.get(i,0)

and then using your suggestion:

#!/usr/bin/python
a ={}
c = 10000
for i in xrange(c*10):
b = i%c
try:
a[i] += 1
except KeyError:
a[i] = i

timing these shows the try clause almoist QUADRUPLES the time: the first runs in 0.62 seconds and the latter runs in 2.4 seconds!!!

Now here is the is the point I was making in my original post: if you try this without using the get its almost 6 times faster than using the .get format and 24 times faster than doing it with the try statement!!!!!!!

To show this consider the following example: In this special problem we know ahead of time what the keys will be. In general we would probably not know this if we were say parsing a file. But since we know them its cheap to write a loop to initialize them first. then we dont have use the get() statement or the try. then we can see how much speed we are losing to the get() statement.

#!/usr/bin/python
a ={}
c = 10000
for i in xrange(c):
a[i] = 0

for i in xrange(c*10):
b = i%c
a[i] += 1

this runs in 0.11 seconds. Which is about 24 times slower than using the try.

your information about how to replace autointialization appears to be seriously mistaken.

Re:Whoa, this is all crazyness.

[Ian Bicking]

If you are writing code that only gets run infrequently and needs to work, you need to use unit testing. It's not a good idea, you ABSOLUTELY MUST TEST. Unless it doesn't matter if it works, and then who cares?

You'll be able to write the code in Python, and the tests, in less time than most statically typed languages. Many would argue that you can write code and tests in any language faster than writing WORKING code without tests... but that starts down a different avenue of discussion.

Re:Toenails

[Ian Bicking]

Ruby is a fine language, and if Python didn't exist I'd probably be using it. But I think Python has some advantages. Off the top of my head:

1. Older
2. More mature: used by a wider variety of people for a wider variety of tasks, community process more developed
3. Unicode
4. Syntactically simpler; less punctuation
5. There Should Only Be One (Best) Way To Do It (not always succeding -- but at least we try)
6. Less opportunity to globally effect the language/process -- e.g., you can't change the behavior of strings throughout the system
7. Larger community
8. More libraries and software
9. Better OS support -- standard on most Linuxes, Mac OS X
10. Some corporate support (e.g., IronPython); EU funding
11. Distributing Python apps fairly easy. Large-scale distributions have been successful (e.g., BitTorrent, iPodder)
12. OS-level threading (I don't believe Ruby has this, though I think they are trying to add it)

Well, those are the ones I can think of now.