Is Python suitable for a huge, enterprise size app?

[Paul Rubin]

"Kay Schluehr" <kay.schluehr at gmx.net> writes:
> To answer Your initial question: there is probably no technical reason
> against Python as a language or the CPython runtime. Both are very
> stable and mature.

I'd like to agree with this but I just can't.  Python is a great
language for prototyping and trying stuff out.  It's fast and pleasant
to write.  But you're right when you say that constant testing and
integration is absolutely necessary to develop anything substantial in
Python.  That is not a virtue, it's a fact that you need all that
testing and correction because it's so easy to make errors and break
things.  The implementation is not so solid either.  I find I file a
few bug reports in sourceforge (or these days often don't even bother)
just about every time I code something new in Python.  I don't know if
language bugs discovered per kLOC written is a normal metric, but for
CPython, in my experience, I'd have to say that number is rather high
as compared with other languages.  Examples I've found in just the
past couple days:

   1) the socket module messes with instance variables on socket
      objects in a way that stops the obvious
         class logging_socket(socket):
            # version of socket that logs all output to the console
            def send(self, mesg):
                print 'socket sending', repr(msg)
                socket.send(self, mesg)
     from working properly.  This cost me about an hour of head scratching
     to figure out what was going on.  Some might say nothing is wrong,
     others might say the socket module could use some reorganization,
     but I'd say it's a questionable feature of the Python language
     that this kind of bug can exist at all.  I'm not a Java expert but
     I believe this particular bug would be impossible in Java.

   2) If you want to display a gif image in tkinter, you can make a
      frame object, put a canvas in it, and put a PhotoImage object
      onto the canvas, which works fine.  But if you use your own
      subclass of frame (maybe to add your own gui stuff), for some
      reason the gif doesn't display in the canvas.  Also, if you run
      your frame's mainloop in its own thread, the gif sometimes
      doesn't display.  I'm still trying to figure this one out.  And
      every incident like this means I'm spending my time debugging
      the Python library instead of writing my own code.

The documentation is spotty (Tkinter?  Hah.) and the runtime library's
idea of supporting some protocol or standard is often to implement
some simple cases and not bother with the more difficult details.  So
users tend to look in the manual and say "yeah, Python supports
[whatever]" and then get bitten later when they find that the support
for [whatever] is quite incomplete (look at the socket module's SSL
support, which doesn't bother validating the certificates, for an
extreme example, but it's similar with urllib, imaplib, etc.)  Python
advocates also tend to say "Python supports such-and-such" if there's
a 3rd party module that supports it (e.g. the standard distro has no
support whatsoever for SQL server connectivity, so the OP's megabuck
app's developers will have to deal with a different set of maintainers
for some ODBC class than for the stdlib).  An old version of the
Twisted Matrix docs explained why Twisted reimplemented so much stuff
that was already in CPython, saying something like "it may look like
we're reinventing the wheel, but we found the old wheels were often
square and made of glue".  Or as Jamie Zawinski said about X-Windows,
"using these toolkits is like trying to make a bookshelf out of mashed
potatoes."

Java's runtime library has a rather ugly and tasteless design compared
with Python's, but it's much more thorough (includes JDBC, JSSE, a
more serious threading implementation, etc.), the documentation
coverage is pretty good, and when they implement a standard, they do
tend to implement it completely.

I'm in the middle of prototyping something in Python and it's going
pretty well despite occasional snags like those mentioned above.  But
at the end of the day I don't think what we get will be solid enough
for use in production.  We're planning to use the Python prototype to
get the feature set and protocols figured out, then reimplement in Java.  
The OP might consider that approach.