From 98839e906632dfe77c6f6906d61d62868a0541dc Mon Sep 17 00:00:00 2001 From: Tim Graham Date: Thu, 31 Dec 2015 14:29:52 -0500 Subject: [PATCH] Removed British/Austrialian word: whilist. --- django/contrib/sessions/backends/base.py | 2 +- django/views/decorators/http.py | 2 +- docs/topics/conditional-view-processing.txt | 2 +- docs/topics/db/models.txt | 4 ++-- docs/topics/db/transactions.txt | 2 +- tests/unmanaged_models/tests.py | 2 +- 6 files changed, 7 insertions(+), 7 deletions(-) diff --git a/django/contrib/sessions/backends/base.py b/django/contrib/sessions/backends/base.py index a4480afabf..718cc54215 100644 --- a/django/contrib/sessions/backends/base.py +++ b/django/contrib/sessions/backends/base.py @@ -295,7 +295,7 @@ class SessionBase(object): def cycle_key(self): """ - Creates a new session key, whilst retaining the current session data. + Creates a new session key, while retaining the current session data. """ data = self._session_cache key = self.session_key diff --git a/django/views/decorators/http.py b/django/views/decorators/http.py index 15e89176fd..bef9ea61a9 100644 --- a/django/views/decorators/http.py +++ b/django/views/decorators/http.py @@ -61,7 +61,7 @@ def condition(etag_func=None, last_modified_func=None): The parameters are callables to compute the ETag and last modified time for the requested resource, respectively. The callables are passed the same parameters as the view itself. The Etag function should return a string (or - None if the resource doesn't exist), whilst the last_modified function + None if the resource doesn't exist), while the last_modified function should return a datetime object (or None if the resource doesn't exist). If both parameters are provided, all the preconditions must be met before diff --git a/docs/topics/conditional-view-processing.txt b/docs/topics/conditional-view-processing.txt index ed319474fa..1af587c225 100644 --- a/docs/topics/conditional-view-processing.txt +++ b/docs/topics/conditional-view-processing.txt @@ -184,7 +184,7 @@ Comparison with middleware conditional processing You may notice that Django already provides simple and straightforward conditional ``GET`` handling via the :class:`django.middleware.http.ConditionalGetMiddleware` and -:class:`~django.middleware.common.CommonMiddleware`. Whilst certainly being +:class:`~django.middleware.common.CommonMiddleware`. While certainly being easy to use and suitable for many situations, those pieces of middleware functionality have limitations for advanced usage: diff --git a/docs/topics/db/models.txt b/docs/topics/db/models.txt index bb41dc6f6f..08ea426690 100644 --- a/docs/topics/db/models.txt +++ b/docs/topics/db/models.txt @@ -928,7 +928,7 @@ model, since it is an abstract base class. It does not generate a database table or have a manager, and cannot be instantiated or saved directly. For many uses, this type of model inheritance will be exactly what you want. -It provides a way to factor out common information at the Python level, whilst +It provides a way to factor out common information at the Python level, while still only creating one database table per child model at the database level. ``Meta`` inheritance @@ -1011,7 +1011,7 @@ Along with another app ``rare/models.py``:: pass The reverse name of the ``common.ChildA.m2m`` field will be -``common_childa_related``, whilst the reverse name of the +``common_childa_related``, while the reverse name of the ``common.ChildB.m2m`` field will be ``common_childb_related``, and finally the reverse name of the ``rare.ChildB.m2m`` field will be ``rare_childb_related``. It is up to you how you use the ``'%(class)s'`` and ``'%(app_label)s`` portion diff --git a/docs/topics/db/transactions.txt b/docs/topics/db/transactions.txt index 8c2474d527..05a1771d74 100644 --- a/docs/topics/db/transactions.txt +++ b/docs/topics/db/transactions.txt @@ -601,7 +601,7 @@ Handling exceptions within PostgreSQL transactions Inside a transaction, when a call to a PostgreSQL cursor raises an exception (typically ``IntegrityError``), all subsequent SQL in the same transaction will fail with the error "current transaction is aborted, queries ignored -until end of transaction block". Whilst simple use of ``save()`` is unlikely +until end of transaction block". While simple use of ``save()`` is unlikely to raise an exception in PostgreSQL, there are more advanced usage patterns which might, such as saving objects with unique fields, saving using the force_insert/force_update flag, or invoking custom SQL. diff --git a/tests/unmanaged_models/tests.py b/tests/unmanaged_models/tests.py index 50b123eef6..e98cee8ae1 100644 --- a/tests/unmanaged_models/tests.py +++ b/tests/unmanaged_models/tests.py @@ -12,7 +12,7 @@ class SimpleTests(TestCase): """ The main test here is that the all the models can be created without any database errors. We can also do some more simple insertion and - lookup tests whilst we're here to show that the second of models do + lookup tests while we're here to show that the second of models do refer to the tables from the first set. """ # Insert some data into one set of models.