summaryrefslogtreecommitdiff
path: root/docs/narr
diff options
context:
space:
mode:
Diffstat (limited to 'docs/narr')
-rw-r--r--docs/narr/introduction.rst8
1 files changed, 4 insertions, 4 deletions
diff --git a/docs/narr/introduction.rst b/docs/narr/introduction.rst
index ef7615079..696901a32 100644
--- a/docs/narr/introduction.rst
+++ b/docs/narr/introduction.rst
@@ -456,9 +456,9 @@ No singletons
Pyramid is written in such a way that it requires your application to have
exactly zero "singleton" data structures. Or, put another way, Pyramid
doesn't require you to construct any "mutable globals". Or put even a
-different way, an import of a Pyramid application needn't have any "import-
-time side effects". This is esoteric-sounding, but if you've ever tried to
-cope with parameterizing a Django "settings.py" file for multiple
+different way, an import of a Pyramid application needn't have any
+"import-time side effects". This is esoteric-sounding, but if you've ever
+tried to cope with parameterizing a Django "settings.py" file for multiple
installations of the same application, or if you've ever needed to
monkey-patch some framework fixture so that it behaves properly for your use
case, or if you've ever wanted to deploy your system using an asynchronous
@@ -503,7 +503,7 @@ data if you're not extremely careful. Some data will have been written to
the database that probably should not have. Having a centralized commit
point saves you from needing to think about this; it's great for lazy people
who also care about data integrity. Either the request completes
-successfully, and all chages are committed, or it does not, and all changes
+successfully, and all changes are committed, or it does not, and all changes
are aborted.
Also, Pyramid's transaction management system allows you to synchronize