neither C nor Python is adequate to address the development bottleneck; together, they
can do much more. As shown in Figure 21-4, for instance, apart from standalone use,
one of Python’s most common roles splits systems into frontend components that can
benefit from Python’s ease of use and backend modules that require the efficiency of
static languages such as C, C++, or FORTRAN.
Figure 21-4. Hybrid designs
Whether we add Python frontend interfaces to existing systems or design them in early
on, such a division of labor can open up a system to its users without exposing its
internals.
When developing new systems, we also have the option of writing entirely in Python
at first and then optimizing as needed for delivery by moving performance-critical
components to compiled languages. And because Python and C modules look the same
to clients, migration to compiled extensions is transparent.
Prototyping doesn’t make sense in every scenario. Sometimes splitting a system into a
Python frontend and a C/C++ backend up front works best. And prototyping doesn’t
help much when enhancing existing systems. But where it can be applied, early pro-
totyping can be a major asset. By prototyping in Python first, we can show results more
quickly. Perhaps more critically, end users can be closely involved in the early stages
of the process, as sketched in Figure 21-5. The result is systems that more closely reflect
their original requirements.
On Sinking the Titanic
In short, Python is really more than a language; it implies a development philosophy.
The concepts of prototyping, rapid development, and hybrid applications certainly
aren’t new. But while the benefits of such development modes are widely recognized,
there has been a lack of tools that make them practical without sacrificing programming
power. This is one of the main gaps that Python’s design fills: Python provides a simple
1552 | Chapter 21: Conclusion: Python and the Development Cycle