diff options
Diffstat (limited to 'docs/topics')
| -rw-r--r-- | docs/topics/auth/customizing.txt | 4 | ||||
| -rw-r--r-- | docs/topics/db/optimization.txt | 2 | ||||
| -rw-r--r-- | docs/topics/db/queries.txt | 4 | ||||
| -rw-r--r-- | docs/topics/forms/index.txt | 4 | ||||
| -rw-r--r-- | docs/topics/forms/modelforms.txt | 2 | ||||
| -rw-r--r-- | docs/topics/http/sessions.txt | 2 | ||||
| -rw-r--r-- | docs/topics/migrations.txt | 2 |
7 files changed, 10 insertions, 10 deletions
diff --git a/docs/topics/auth/customizing.txt b/docs/topics/auth/customizing.txt index 382fc94a6b..38ee57240f 100644 --- a/docs/topics/auth/customizing.txt +++ b/docs/topics/auth/customizing.txt @@ -77,7 +77,7 @@ backends that follow. .. note:: Once a user has authenticated, Django stores which backend was used to - authenticate the user in the user's session, and re-uses the same backend + authenticate the user in the user's session, and reuses the same backend for the duration of that session whenever access to the currently authenticated user is needed. This effectively means that authentication sources are cached on a per-session basis, so if you change @@ -229,7 +229,7 @@ Django's permission framework does not have a place to store permissions for anonymous users. However, the user object passed to an authentication backend may be an :class:`django.contrib.auth.models.AnonymousUser` object, allowing the backend to specify custom authorization behavior for anonymous users. This -is especially useful for the authors of re-usable apps, who can delegate all +is especially useful for the authors of reusable apps, who can delegate all questions of authorization to the auth backend, rather than needing settings, for example, to control anonymous access. diff --git a/docs/topics/db/optimization.txt b/docs/topics/db/optimization.txt index 166d50710f..ca04c8fd55 100644 --- a/docs/topics/db/optimization.txt +++ b/docs/topics/db/optimization.txt @@ -289,7 +289,7 @@ It is optimal because: ``display_group_members`` is ``False``. #. Storing ``group.members.all()`` in the ``members`` variable allows its - result cache to be re-used. + result cache to be reused. #. The line ``if members:`` causes ``QuerySet.__bool__()`` to be called, which causes the ``group.members.all()`` query to be run on the database. If there diff --git a/docs/topics/db/queries.txt b/docs/topics/db/queries.txt index af26462367..c6349792b7 100644 --- a/docs/topics/db/queries.txt +++ b/docs/topics/db/queries.txt @@ -810,7 +810,7 @@ reuse it:: >>> queryset = Entry.objects.all() >>> print([p.headline for p in queryset]) # Evaluate the query set. - >>> print([p.pub_date for p in queryset]) # Re-use the cache from the evaluation. + >>> print([p.pub_date for p in queryset]) # Reuse the cache from the evaluation. When ``QuerySet``\s are not cached ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1640,7 +1640,7 @@ instances:: b = Blog.objects.get(id=1) b.entry_set.set([e1, e2]) -If the ``clear()`` method is available, any pre-existing objects will be +If the ``clear()`` method is available, any preexisting objects will be removed from the ``entry_set`` before all objects in the iterable (in this case, a list) are added to the set. If the ``clear()`` method is *not* available, all objects in the iterable will be added without removing any diff --git a/docs/topics/forms/index.txt b/docs/topics/forms/index.txt index 0e98e50692..e7709834c2 100644 --- a/docs/topics/forms/index.txt +++ b/docs/topics/forms/index.txt @@ -164,7 +164,7 @@ So when we handle a model instance in a view, we typically retrieve it from the database. When we're dealing with a form we typically instantiate it in the view. -When we instantiate a form, we can opt to leave it empty or pre-populate it, for +When we instantiate a form, we can opt to leave it empty or prepopulate it, for example with: * data from a saved model instance (as in the case of admin forms for editing) @@ -207,7 +207,7 @@ Now you'll also need a view corresponding to that ``/your-name/`` URL which will find the appropriate key/value pairs in the request, and then process them. This is a very simple form. In practice, a form might contain dozens or -hundreds of fields, many of which might need to be pre-populated, and we might +hundreds of fields, many of which might need to be prepopulated, and we might expect the user to work through the edit-submit cycle several times before concluding the operation. diff --git a/docs/topics/forms/modelforms.txt b/docs/topics/forms/modelforms.txt index 26a5fc8b0f..3332709089 100644 --- a/docs/topics/forms/modelforms.txt +++ b/docs/topics/forms/modelforms.txt @@ -820,7 +820,7 @@ Then, pass your ``BaseAuthorFormSet`` class to the factory function:: >>> AuthorFormSet = modelformset_factory( ... Author, fields=('name', 'title'), formset=BaseAuthorFormSet) -If you want to return a formset that doesn't include *any* pre-existing +If you want to return a formset that doesn't include *any* preexisting instances of the model, you can specify an empty QuerySet:: >>> AuthorFormSet(queryset=Author.objects.none()) diff --git a/docs/topics/http/sessions.txt b/docs/topics/http/sessions.txt index c5c78a263a..553fb06a61 100644 --- a/docs/topics/http/sessions.txt +++ b/docs/topics/http/sessions.txt @@ -609,7 +609,7 @@ of ``request.session`` as described above in `using sessions in views`_. .. note:: Some browsers (Chrome, for example) provide settings that allow users to - continue browsing sessions after closing and re-opening the browser. In + continue browsing sessions after closing and reopening the browser. In some cases, this can interfere with the :setting:`SESSION_EXPIRE_AT_BROWSER_CLOSE` setting and prevent sessions from expiring on browser close. Please be aware of this while testing diff --git a/docs/topics/migrations.txt b/docs/topics/migrations.txt index 73dec300e0..3f443e867b 100644 --- a/docs/topics/migrations.txt +++ b/docs/topics/migrations.txt @@ -426,7 +426,7 @@ historical model versions rather than importing them directly. If you import models directly rather than using the historical models, your migrations *may work initially* but will fail in the future when you - try to re-run old migrations (commonly, when you set up a new installation + try to rerun old migrations (commonly, when you set up a new installation and run through all the migrations to set up the database). This means that historical model problems may not be immediately obvious. |