Python in the enterprise: Pros and cons

[Paul Rubin]

"David LeBlanc" <whisper at oz.net> writes:
> * Lack of true multiprocessor support
> 
> -- Heh. That's not really true either. Python is no better and no worse then
> any other application program wrt to multiprocessor usage. What the author
> probably was referring to here is Python's lack of multi-processor
> multi-threading - i.e. true parallel computation. Know many non-specialized
> languages that can or do exploit multi-processor multi-threading? There are
> even OS dependencies: Win32 OS's (NT, 2k, XP) will not spread applications
> across processors unless your program causes it to explicitly (this is at
> least true on retail 2 processor maximum systems). Linux OTOH, does so.

I thought NT could use multi-processor multi-threading.  I don't see
any issue about having to tell it to.  If you could tell Python to use
multiple processors, that would count too.  

> * Software performance (though benchmarks repeatedly demonstrate Python is
> comparable to Java in most applications)
> 
> -- "Python is comparable to Java" is probably a con - Python far surpasses
> Java in the shortness of time spent going from "hmmm ..." to "run ...". If
> you're comparing clock cycles, then you're saying an open source development
> project has done what a multi-billion dollar company with 100's of
> developers has done (that's a bit unfair - Python probably has more
> developers (including "battery" developers) on it then does Java). Python
> can and most likely will get faster and even more popular, but I'm not sure
> the same can be said for Java.

There are almost certainly more people writing Java stuff than Python
stuff.  Python wins big in development speed and development speed is
important, but it's not always the only thing.  Sometimes you care how
fast your program runs AFTER you've written it.  And native-code Java
compilers like gcj completely beat the pants off Python in terms of
execution speed.  There are some projects like psyco which aim to
narrow that gap, but they're not yet ready for prime time.

> * Lack of prepackaged solutions
> 
> -- Take a look at the Python foundry on SourceForge. Browse the
> comp.lang.python.announce archives. Spend an afternoon in the Vaults of
> Parnassas, Python's defacto standard repository/catalog for contributed
> software. Search for "python applications" on Google or Yahoo. Try "python
> <application name>" for whatever type of application you're looking for and
> see what comes up. Lack of channels for promoting Python applications
> doesn't mean they don't exist.

Regardless of that, lots of stuff has been written in Java that's
never been written in Python.  Where's the Python TLS stack with
certificate management?  Where are the Enterprise Python Beans?  Where
is the JCE-like Python cryptography library with hardware service
providers (answer to that one: I'm writing it but it has a ways to
go)?  Where's the Python ODBC interface (ans: it exists but you have
to pay for it)?  The list goes on, and that's just Java.  

> * Documentation gaps
> 
> -- This was recently discussed on comp.lang.python. There are at least 27
> books dealing with Python or Python in specific applications. The "in the
> box" documentation is ackward to use but reasonably comprehesive (tutorial
> aside - the best basic introduction is the book "Learning Python" by Mark
> Lutz). 

Yes, those are documentation gaps.  You have to actually go out buy
chunks of dead tree pulp in order to use this documentation, and then
let it encroach heavily into your working/living space if you want to
keep it around for future reference.  To me, these problems greatly
decreases its value of such docs.  Java's online docs are far superior
to Python's.  There are also a lot more books about Java, but I don't
care about those for the same reason I don't care about Python books.

> There are at least 2 full books for Python online: DiveIntoPython and
> "How To Think Like A Computer Scientist" (using Python), and many other
> online resources available through Python.org.

These are tutorials and neither of them attempts to be complete references.

> * Absence of GUI and teamwork tools
> 
> -- There two commercial tools for wysiwyg tkinter development, one of which
> is PythonWorks from Pythonware. Do CVS and Subversion count as teamwork
> tools? They do solve the source management part. MoinMoin Wiki software will
> solve the team interaction part of the equation, and there are chat packages
> out there, including a Jabber client for instant messaging on all the
> popular IM networks. It's a product opportunity for someone to integrate all
> the tools into a cohesive whole, but all the parts seem to be there...

I'm not too impressed by any of those but I'm not impressed by Swing
or AWT either, so it balances out.

> The one thing that has come to mind from writing this as a con for Python is
> the lack of channels for widespread dissemination of information about
> commercial software applications, support and consulting. Python does need
> better publicizing in the marketplace. Python.org provides such a focus for
> information about the language, but provides little beyond a jobs board for
> the marketplace. It would be nice to see a registry of products and services
> that use or support Python.
> 
> My conclusion is that Python is entirely ready for the enterprise - and it's
> already there!

Python is ready for some applications and getting there for others.
It has a lot of virtues and to be clear about it, I like Python better
than Java for most purposes.  However, Python's advocates often don't
acknowledge that there are still areas where Python genuinely does
fall behind.  We need to stay aware of Python's shortcomings so we can
acknowledge them and/or fix them.