Is Python suitable for a huge, enterprise size app?

[john67]

The company I work for is about to embark on developing a commercial
application that will cost us tens-of-millions to develop. When all is
said and done it will have thousands of business objects/classes, some
of which will have hundreds-of-thousands of instances stored in a DB.
Our clients will probably have somewhere between 50-200 users working
on the app during the day, possibly in mutiple offices, and then a
large number of batch processes will have to run each night. It will
also need to have a web interface for certain users. It needs to be
robust, easy to maintain, and able to be customized for each client.

Right now it looks like Java is the language of choice that the app
will be developed in. However, I have been looking and reading a lot
about Python recently and it seems to me that Python could handle it.
The big attraction to me is the developer productivity. It seems that
if Python can handle it, then we could gain a huge savings by using
Python instead of Java from a productivity standpoint alone.

So, given the very general requirements in the first paragraph, do you
think that Python could handle it? If anyone has direct experience
developing large apps in Python, I would appreciate your insight.
Based on the responses I get, I am planning on writing a proposal to my
management to consider Python instead of Java.

Thanks,
John

[Antoon Pardon]

Op 2005-05-20, Dieter Maurer schreef <di****@handshake.de>:

"Fredrik Lundh" <fr*****@pythonware.com> writes on Thu, 19 May 2005 09:54:15 +0200:

...
and unless your operating system is totally braindead, and thus completely unfit
to run huge enterprise size applications, that doesn't really matter much. leaks
are problematic, large peak memory use isn't.

Could you elaborate a bit?

Large peak memory use means that the application got a large
address space. What garantees that the residual memory use
(after the peak) is compact and not evenly spread across
the address space.

Well nothing. But how do you want to return memory back
to the O.S. when the residual memory use isn't compact
and evenly spread across the address space?

--
Antoon Pardon

[Paul Rubin]

Antoon Pardon <ap*****@forel.vub.ac.be> writes:

Well nothing. But how do you want to return memory back
to the O.S. when the residual memory use isn't compact
and evenly spread across the address space?

All large-scale language implementations with automatic storage
management that I know of use compacting storage schemes, e.g. copying
garbage collectors (maybe generational, multi-threaded/realtime, or
whatever). I think Python will have to do the same, sooner or later.

[Fredrik Lundh]

Dieter Maurer wrote:

Could you elaborate a bit?

Large peak memory use means that the application got a large
address space. What garantees that the residual memory use
(after the peak) is compact and not evenly spread across
the address space.

nothing guarantees that, of course. but I've never seen that
happen. and I'm basing my comments on observed behaviour in
real systems, not on theoretical worst-case scenarios. every
time I've seen serious fragmentation, it's been related to leaks,
not peak memory usage.

</F>

[Dieter Maurer]

"Fredrik Lundh" <fr*****@pythonware.com> writes on Tue, 24 May 2005 22:38:05 +0200:

...
nothing guarantees that, of course. but I've never seen that
happen. and I'm basing my comments on observed behaviour in
real systems, not on theoretical worst-case scenarios.
I observed in real systems (Zope) that the system got slower
and slower as the amount of allocated memory increased -- although
the OS was far from its memory resource limits (and virtual memory size
was not much larger then resident memory size). Flushing caches
(and thereby releasing most memory) did not speed up things
but restarting did.

I do not understand this observed behaviour.
every
time I've seen serious fragmentation, it's been related to leaks,
not peak memory usage.

An analysis did not reveal serious leaks, in the cases mentioned above.
Dieter