Python for large projects

[Cameron Laird]

In article <7xisgxt51r.fsf at ruckus.brouhaha.com>,
Paul Rubin  <http://phr.cx@NOSPAM.invalid> wrote:
>assaf__ at walla.com writes:
>> I am beginning to work on a fairly large project and I'm considering
>> to use python for most of the coding, but I need to make sure first
>> that it is reliable enough.
>> 
>> I need to make sure that I won't have surprises when my program runs
>> on different real-world systems. So far I wrote a little script with
>> python using urllib, and on one computer it failed completely
>> because of a problem in getting the proxies (in my opinion this is a
>> bug). How likely are such things to happen and how often, and to
>> what extent are they more prevalent in python in comparison to C++?
>
>The Python language is in general well-designed and much more concise
>than C++.  A big program in C++ may map to a much smaller Python
>program, turning a large project into a small project, and making it
>less relevant whether Python works for large projects.
>
>Python's library does have a lot of small gaps like the one you found
>in urllib.  As the Twisted Matrix documentation puts it, you find
>yourself re-inventing the wheel a lot, because you discover that the
>existing wheels are often square and made of glue.
>
>> If python is indeed suitable for large projects, how common is it to
>> actually use if for such purposes? Is there perhaps a list of
>> examples of real projects using python?
>
>The canonical example of a complex Python project is Zope
>(www.zope.com).  It's medium sized by the standards of big C++
>projects, but as mentioned, a medium amount of Python code can
>implement functionality that would take a much larger amount of C++.
>
>Because Python is interpreted and highly dynamic, Python programs tend
>to run slower than comparable C++ programs.  Whether that's a problem
>for you depends on your application.  If you have specific Python
>functions that are bottlenecks, you can re-implement them in C and
>call them through Python's C API.  There's also a semi-experimental
>native-code Python compiler called Psyco that produces a considerable
>speedup at the cost of increased memory consumption.  The
>next-generation Python implementation (PyPy or Python in Python) will
>reportedly use Psyco or something simliar, in a more fundamental way.
>
>In short, there's not a quick and simple answer to your question of
>whether Python is right for what you're doing.  It's great for lots of
>things, not so hot for some others, and is still evolving rather
>quickly, so an unsuitable application today may become suitable in a
>forthcoming release.

You might also have occasion to learn about Pyrex and
... well, I'm in the Trotskyite wing on this question.
It's not just that Python can work for large projects.
I sincerely regard it as an even *better* comparative
choice on large projects; C++ and Java, the usual com-
petition, show all sorts of blemishes when one scales
the size of the project.  Python remains usable, even
at the high end.
-- 

Cameron Laird <claird at phaseit.net>
Business:  http://www.Phaseit.net