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?

[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?

[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?

[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?

[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

[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

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

Did anyone else think...

[lxt]

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

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

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

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

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

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

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?

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

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

[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?

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.

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.

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

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