wording

Chris McDonough

2010-12-25 b36921fa658dd15db788adc6b03b10dd6d035dd3

wording

 docs/designdefense.rst

@@ -22,13 +22,12 @@
via :term:`url dispatch` or :term:`traversal`.  Multiple methods of
configuration exist: :term:`imperative configuration`, :term:`configuration
decoration`, and :term:`ZCML`. A view callable can itself be either a
function, an instance, or a class.  There are multiple ways to serve static
files.  It works with multiple different kinds of persistence and templating
systems.  And so on.  However, the existence of most of these overlapping
ways to do things are not without reason and purpose: we have a number of
audiences to serve, and we believe that TIMTOWTI at the web framework level
actually *prevents* a much more insidious and harmful set of duplication at
higher levels in the Python web community.
function, an instance, or a class.  It works with multiple different kinds of
persistence and templating systems.  And so on.  However, the existence of
most of these overlapping ways to do things are not without reason and
purpose: we have a number of audiences to serve, and we believe that TIMTOWTI
at the web framework level actually *prevents* a much more insidious and
harmful set of duplication at higher levels in the Python web community.

:app:`Pyramid` began its life as :mod:`repoze.bfg`, written by a team of
people with many years of prior :ref:`Zope` experience.  The idea of
@@ -40,15 +39,14 @@
Implementations of these features were *required* to allow the :app:`Pyramid`
authors to build the bread-and-butter CMS-type systems for customers in the
way they were accustomed to building them.  No other system save Zope itself
had such features.  And Zope itself was beginning to show signs of its age,
and we were becoming hampered by consequences of early design mistakes.
Zope's lack of documentation was also difficult to work around: it was hard
to hire otherwise-smart people to work on Zope applications, because there
was no comprehensive documentation set to point them at which explained "it
all" in one consumble place.  Before :mod:`repoze.bfg` went under
development, its authors obviously looked around for other frameworks that
fit the bill.  But no non-Zope framework did.  So we embarked on building
:mod:`repoze.bfg`.
had such features.  And Zope itself was beginning to show signs of its age.
W were becoming hampered by consequences of early design mistakes.  Zope's
lack of documentation was also difficult to work around: it was hard to hire
smart people to work on Zope applications, because there was no comprehensive
documentation set to point them at which explained "it all" in one consumble
place.  Before :mod:`repoze.bfg` went under development, its authors
obviously looked around for other frameworks that fit the bill.  But no
non-Zope framework did.  So we embarked on building :mod:`repoze.bfg`.

As the result of our research, however, it became apparent that, despite the
fact that no *one* framework had all the features we required, lots of
@@ -68,31 +66,35 @@
appeal to non-Zope users as well as ex-Zope users.

As the result of this generalization, it became obvious BFG shared 90% of its
featureset with the featureset of Pylons 1, and had a very similar target
market.  Because they were so similar, choosing between the two systems was
an exercise in frustration for an otherwise non-partisan developer.  It was
also painful and felt wrong for Pylons and BFG development communities to
compete for users.  So the Pylons and BFG teams began to work together to
form a plan to "merge".  The features missing from BFG (notably :term:`view
handler` classes, flash messaging, and other minor missing bits), were added,
to provide familiarity to ex-Pylons users.  The result is :app:`Pyramid`.
featureset with the featureset of Pylons 1, and thus had a very similar
target market.  Because they were so similar, choosing between the two
systems was an exercise in frustration for an otherwise non-partisan
developer.  It was also painful and felt wrong for Pylons and BFG development
communities to compete for users.  So the Pylons and BFG teams began to work
together to form a plan to "merge".  The features missing from BFG (notably
:term:`view handler` classes, flash messaging, and other minor missing bits),
were added, to provide familiarity to ex-Pylons users.  The result is
:app:`Pyramid`.

The Python web framework space is currently notoriously balkanized.  We're
truly hoping that the amalgamation of components in :app:`Pyramid` will
appeal to at least two currently very distinct sets of users: Pylons and BFG
(often ex-Zope) users.  By unifying the best concepts from Pylons and BFG
into a single codebase and leaving the bad concepts from their ancestors
behind, we'll be able to consolidate our efforts better, share more code, and
promote our efforts as a unit rather than competing pointlessly.  We hope to
be able to shortcut the pack mentality which results in a *much larger*
duplication of effort, represented by competing but incredibly similar
applications and libraries, each built upon a specific low level stack that
is incompatible with the other.  We'll also shrink the choice of credible
Python web frameworks down by at least one.  Some overlap of functionality to
achieve these goals is expected and unavoidable, at least if we aim to
prevent pointless duplication at higher levels.  If we've done our job well
enough, the various audiences will be able to coexist and cooperate rather
than firing at each other across some imaginary web framework "DMZ".
users.  By unifying the best concepts from Pylons and BFG into a single
codebase and leaving the bad concepts from their ancestors behind, we'll be
able to consolidate our efforts better, share more code, and promote our
efforts as a unit rather than competing pointlessly.  We hope to be able to
shortcut the pack mentality which results in a *much larger* duplication of
effort, represented by competing but incredibly similar applications and
libraries, each built upon a specific low level stack that is incompatible
with the other.  We'll also shrink the choice of credible Python web
frameworks down by at least one.  We're also hoping to attract users from
other communities (such as Zope's and TurboGears') by providing the features
they need, while allowing enough flexibility to do thing in a familiar
fashion.  Some overlap of functionality to achieve these goals is expected
and unavoidable, at least if we aim to prevent pointless duplication at
higher levels.  If we've done our job well enough, the various audiences will
be able to coexist and cooperate rather than firing at each other across some
imaginary web framework "DMZ".

Pyramid Uses A Zope Component Architecture ("ZCA") Registry
-----------------------------------------------------------