Is Python suitable for a huge, enterprise size app?

[Dave Brueck]

Paul Rubin wrote:
> Dave Brueck <dave at pythonapocrypha.com> writes:
> 
>>>What do you use for HTTPS?
>>
>>m2crypto (plus some patches to make asynchronous SSL do what we needed).
> 
> 
> That seems to be a nice piece of code, but it's still at version 0.13;

Version numbers are fairly relative, though. In another project we're using some 
proprietary, closed source libraries (unrelated to crypto) that are version 3 
and they seem buggier and less stable than m2crypto.

And don't get me started on Microsoft products (we've been using DirectShow *9* 
in some stuff, and due to bugs in DirectShow we were completely and utterly 
screwed despite what the documentation said; things just didn't work as they 
should, and Microsoft has confirmed that it's a bug that will be fixed in some 
future release - so we had to backtrack, ripping out code that should work just 
fine, and take another stab at getting DirectShow to cooperate). Version NINE 
(supposedly).

> if something goes wrong, are you sure you want to explain that you
> were using beta-test software to protect your customers' production
> financial transactions?

lol - what? We're not doing any financial transactions with it (IOW - we 
evaluated m2crypto for what we needed to do, and it's a good fit - that we 
didn't evaluate it in terms of what we don't need it to do doesn't bother me).

Having said that - I think we probably *would* use it for production financial 
transactions - but that's more a matter of closed vs. open source than Python vs 
not.

Besides, do you really think that, if something went wrong, you'd in the end 
have some meeting where you explain to your customer that you were using beta 
software? Of course not - it just doesn't work that way. Either they won't care 
and will drop you because of the problem (regardless of the source) or they want 
some broad details.

> There's also been some traffic on the
> python-crypto list about Zope encountering memory leaks with it.

Ok... so? I mean, if there's a memory leak, and it's hurting us, we have 
options: we can go look in the source code, we can make Zope reboot itself 
often, we can hire somebody to fix it, we can see if the author wants to give us 
a support contract, etc.

Memory leaks aren't exactly unique to Python - according to bugs.sun.com, there 
are currently 382 *open* bugs related to memory leaks in the JDK alone. If 
you're using Java in your "huge, enterprise size app" and get bit by one of 
those bugs, and if you're not a big enough company to get some 
ridiculously-priced support contract from Sun, what are your options? Again, 
this seems more like an open-vs-closed source issue, but to me it's another 
reason why I'd feel uncomfortable using Java in mission critical work.

-Dave