Refs #30573 -- Rephrased "Of Course" and "Obvious(ly)" in documentation and comments.

django/contrib/contenttypes/models.py

@@ -104,7 +104,7 @@ class ContentTypeManager(models.Manager):
     def get_for_id(self, id):
         """
         Lookup a ContentType by ID. Use the same shared cache as get_for_model
-        (though ContentTypes are obviously not created on-the-fly by get_by_id).
+        (though ContentTypes are not created on-the-fly by get_by_id).
         """
         try:
             ct = self._cache[self.db][id]

django/contrib/gis/db/backends/oracle/introspection.py

@@ -4,9 +4,9 @@ from django.db.backends.oracle.introspection import DatabaseIntrospection
 
 
 class OracleIntrospection(DatabaseIntrospection):
-    # Associating any OBJECTVAR instances with GeometryField.  Of course,
-    # this won't work right on Oracle objects that aren't MDSYS.SDO_GEOMETRY,
-    # but it is the only object type supported within Django anyways.
+    # Associating any OBJECTVAR instances with GeometryField. This won't work
+    # right on Oracle objects that aren't MDSYS.SDO_GEOMETRY, but it is the
+    # only object type supported within Django anyways.
     data_types_reverse = DatabaseIntrospection.data_types_reverse.copy()
     data_types_reverse[cx_Oracle.OBJECT] = 'GeometryField'
 

django/db/migrations/autodetector.py

@@ -89,8 +89,8 @@ class MigrationAutodetector:
     def only_relation_agnostic_fields(self, fields):
         """
         Return a definition of the fields that ignores field names and
-        what related fields actually relate to. Used for detecting renames (as,
-        of course, the related fields change during renames).
+        what related fields actually relate to. Used for detecting renames (as
+        the related fields change during renames).
         """
         fields_def = []
         for name, field in sorted(fields.items()):
@@ -676,9 +676,8 @@ class MigrationAutodetector:
     def generate_created_proxies(self):
         """
         Make CreateModel statements for proxy models. Use the same statements
-        as that way there's less code duplication, but of course for proxy
-        models it's safe to skip all the pointless field stuff and just chuck
-        out an operation.
+        as that way there's less code duplication, but for proxy models it's
+        safe to skip all the pointless field stuff and chuck out an operation.
         """
         added = self.new_proxy_keys - self.old_proxy_keys
         for app_label, model_name in sorted(added):

django/middleware/locale.py

@@ -11,7 +11,7 @@ class LocaleMiddleware(MiddlewareMixin):
     """
     Parse a request and decide what translation object to install in the
     current thread context. This allows pages to be dynamically translated to
-    the language the user desires (if the language is available, of course).
+    the language the user desires (if the language is available).
     """
     response_redirect_class = HttpResponseRedirect
 

django/template/defaulttags.py

@@ -699,7 +699,7 @@ def firstof(parser, token):
             {{ var3 }}
         {% endif %}
 
-    but obviously much cleaner!
+    but much cleaner!
 
     You can also use a literal string as a fallback value in case all
     passed variables are False::

docs/faq/general.txt

@@ -120,9 +120,9 @@ If you're hungry for acronyms, you might say that Django is a "MTV" framework
 -- that is, "model", "template", and "view." That breakdown makes much more
 sense.
 
-At the end of the day, of course, it comes down to getting stuff done. And,
-regardless of how things are named, Django gets stuff done in a way that's most
-logical to us.
+At the end of the day, it comes down to getting stuff done. And, regardless of
+how things are named, Django gets stuff done in a way that's most logical to
+us.
 
 <Framework X> does <feature Y> -- why doesn't Django?
 =====================================================
@@ -167,11 +167,10 @@ It's a Web framework; it's a programming tool that lets you build websites.
 For example, it doesn't make much sense to compare Django to something like
 Drupal_, because Django is something you use to *create* things like Drupal.
 
-Of course, Django's automatic admin site is fantastic and timesaving -- but
-the admin site is one module of Django the framework. Furthermore, although
-Django has special conveniences for building "CMS-y" apps, that doesn't mean
-it's not just as appropriate for building "non-CMS-y" apps (whatever that
-means!).
+Yes, Django's automatic admin site is fantastic and timesaving -- but the admin
+site is one module of Django the framework. Furthermore, although Django has
+special conveniences for building "CMS-y" apps, that doesn't mean it's not just
+as appropriate for building "non-CMS-y" apps (whatever that means!).
 
 .. _Drupal: https://drupal.org/
 

docs/faq/install.txt

@@ -78,8 +78,8 @@ better supported, the latest version of Python 3 is recommended.
 
 You don't lose anything in Django by using an older release, but you don't take
 advantage of the improvements and optimizations in newer Python releases.
-Third-party applications for use with Django are, of course, free to set their
-own version requirements.
+Third-party applications for use with Django are free to set their own version
+requirements.
 
 Should I use the stable version or development version?
 =======================================================

docs/faq/usage.txt

@@ -12,7 +12,7 @@ Make sure that:
 
 * Said module is on ``sys.path`` (``import mysite.settings`` should work).
 
-* The module doesn't contain syntax errors (of course).
+* The module doesn't contain syntax errors.
 
 I can't stand your template language. Do I have to use it?
 ==========================================================

docs/howto/custom-model-fields.txt

@@ -301,10 +301,10 @@ than disappearing if they take on the old default value.
 
 In addition, try to avoid returning values as positional arguments; where
 possible, return values as keyword arguments for maximum future compatibility.
-Of course, if you change the names of things more often than their position
-in the constructor's argument list, you might prefer positional, but bear in
-mind that people will be reconstructing your field from the serialized version
-for quite a while (possibly years), depending how long your migrations live for.
+If you change the names of things more often than their position in the
+constructor's argument list, you might prefer positional, but bear in mind that
+people will be reconstructing your field from the serialized version for quite
+a while (possibly years), depending how long your migrations live for.
 
 You can see the results of deconstruction by looking in migrations that include
 the field, and you can test deconstruction in unit tests by deconstructing and
@@ -451,8 +451,8 @@ time -- i.e., when the class is instantiated. To do that, implement
 Finally, if your column requires truly complex SQL setup, return ``None`` from
 :meth:`.db_type`. This will cause Django's SQL creation code to skip
 over this field. You are then responsible for creating the column in the right
-table in some other way, of course, but this gives you a way to tell Django to
-get out of the way.
+table in some other way, but this gives you a way to tell Django to get out of
+the way.
 
 The :meth:`~Field.rel_db_type` method is called by fields such as ``ForeignKey``
 and ``OneToOneField`` that point to another field to determine their database

docs/howto/static-files/deployment.txt

@@ -21,9 +21,9 @@ manually or the :func:`post_process
 <django.contrib.staticfiles.storage.StaticFilesStorage.post_process>` method of
 the ``Storage`` class might take care of that.
 
-Of course, as with all deployment tasks, the devil's in the details. Every
-production setup will be a bit different, so you'll need to adapt the basic
-outline to fit your needs. Below are a few common patterns that might help.
+As with all deployment tasks, the devil's in the details. Every production
+setup will be a bit different, so you'll need to adapt the basic outline to fit
+your needs. Below are a few common patterns that might help.
 
 Serving the site and your static files from the same server
 -----------------------------------------------------------

docs/internals/contributing/bugs-and-features.txt

@@ -104,10 +104,9 @@ part of that. Here are some tips on how to make a request most effectively:
   like to see it implemented. Include example code (non-functional is OK)
   if possible.
 
-* Explain *why* you'd like the feature. In some cases this is obvious, but
-  since Django is designed to help real developers get real work done,
-  you'll need to explain it, if it isn't obvious why the feature would be
-  useful.
+* Explain *why* you'd like the feature. Explaining a minimal use case will help
+  others understand where it fits in, and if there are already other ways of
+  achieving the same thing.
 
 If there's a consensus agreement on the feature, then it's appropriate to
 create a ticket. Include a link the discussion on |django-developers| in the

docs/internals/contributing/localizing.txt

@@ -32,9 +32,8 @@ translating or add a language that isn't yet translated, here's what to do:
 
 * Then, click the "Join this Team" button to become a member of this team.
   Every team has at least one coordinator who is responsible to review
-  your membership request. You can of course also contact the team
-  coordinator to clarify procedural problems and handle the actual
-  translation process.
+  your membership request. You can also contact the team coordinator to clarify
+  procedural problems and handle the actual translation process.
 
 * Once you are a member of a team choose the translation resource you
   want to update on the team page. For example the "core" resource refers

docs/internals/contributing/triaging-tickets.txt

@@ -268,8 +268,8 @@ When a ticket has completed its useful lifecycle, it's time for it to be
 closed. Closing a ticket is a big responsibility, though. You have to be sure
 that the issue is really resolved, and you need to keep in mind that the
 reporter of the ticket may not be happy to have their ticket closed (unless
-it's fixed, of course). If you're not certain about closing a ticket, leave a
-comment with your thoughts instead.
+it's fixed!). If you're not certain about closing a ticket, leave a comment
+with your thoughts instead.
 
 If you do close a ticket, you should always make sure of the following:
 

docs/internals/contributing/writing-code/submitting-patches.txt

@@ -82,15 +82,14 @@ As always, more communication is better than less communication!
 Which tickets should be claimed?
 --------------------------------
 
-Of course, going through the steps of claiming tickets is overkill in some
-cases.
+Going through the steps of claiming tickets is overkill in some cases.
 
 In the case of small changes, such as typos in the documentation or small bugs
 that will only take a few minutes to fix, you don't need to jump through the
 hoops of claiming tickets. Submit your patch directly and you're done!
 
-Of course, it is *always* acceptable, regardless whether someone has claimed it
-or not, to submit patches to a ticket if you happen to have a patch ready.
+It is *always* acceptable, regardless whether someone has claimed it or not, to
+submit patches to a ticket if you happen to have a patch ready.
 
 .. _patch-style:
 

docs/intro/tutorial05.txt

@@ -582,9 +582,9 @@ we need to add a similar  constraint to ``DetailView``:
             """
             return Question.objects.filter(pub_date__lte=timezone.now())
 
-And of course, we will add some tests, to check that a ``Question`` whose
-``pub_date`` is in the past can be displayed, and that one with a ``pub_date``
-in the future is not:
+We should then add some tests, to check that a ``Question`` whose ``pub_date``
+is in the past can be displayed, and that one with a ``pub_date`` in the future
+is not:
 
 .. code-block:: python
     :caption: polls/tests.py

docs/intro/tutorial06.txt

@@ -112,10 +112,10 @@ loaded in the top left of the screen.
 
 .. warning::
 
-    Of course the ``{% static %}`` template tag is not available for use in
-    static files like your stylesheet which aren't generated by Django. You
-    should always use **relative paths** to link your static files between each
-    other, because then you can change :setting:`STATIC_URL` (used by the
+    The ``{% static %}`` template tag is not available for use in static files
+    which aren't generated by Django, like your stylesheet. You should always
+    use **relative paths** to link your static files between each other,
+    because then you can change :setting:`STATIC_URL` (used by the
     :ttag:`static` template tag to generate its URLs) without having to modify
     a bunch of paths in your static files as well.
 

docs/ref/applications.txt

@@ -104,9 +104,8 @@ their :setting:`INSTALLED_APPS` setting. Besides this use case, it's best to
 avoid using ``default_app_config`` and instead specify the app config class in
 :setting:`INSTALLED_APPS` as described next.
 
-Of course, you can also tell your users to put
-``'rock_n_roll.apps.RockNRollConfig'`` in their :setting:`INSTALLED_APPS`
-setting. You can even provide several different
+You can also tell your users to put ``'rock_n_roll.apps.RockNRollConfig'`` in
+their :setting:`INSTALLED_APPS` setting. You can even provide several different
 :class:`~django.apps.AppConfig` subclasses with different behaviors and allow
 your users to choose one via their :setting:`INSTALLED_APPS` setting.
 

docs/ref/contrib/contenttypes.txt

@@ -403,8 +403,8 @@ from ``TaggedItem``::
     >>> TaggedItem.objects.filter(bookmark__url__contains='django')
     <QuerySet [<TaggedItem: django>, <TaggedItem: python>]>
 
-Of course, if you don't add the ``related_query_name``, you can do the
-same types of lookups manually::
+If you don't add the ``related_query_name``, you can do the same types of
+lookups manually::
 
     >>> bookmarks = Bookmark.objects.filter(url__contains='django')
     >>> bookmark_type = ContentType.objects.get_for_model(Bookmark)

docs/ref/contrib/sites.txt

@@ -134,8 +134,7 @@ For example::
             # Do something else.
             pass
 
-Of course, it's ugly to hard-code the site IDs like that. This sort of
-hard-coding is best for hackish fixes that you need done quickly. The
+It's fragile to hard-code the site IDs like that, in case they change. The
 cleaner way of accomplishing the same thing is to check the current site's
 domain::
 

docs/ref/databases.txt

@@ -19,8 +19,8 @@ design decisions on which features to support and which assumptions we can make
 safely.
 
 This file describes some of the features that might be relevant to Django
-usage. Of course, it is not intended as a replacement for server-specific
-documentation or reference manuals.
+usage. It is not intended as a replacement for server-specific documentation or
+reference manuals.
 
 General notes
 =============

docs/ref/migration-operations.txt

@@ -173,10 +173,10 @@ defaults and always applies them in the Django ORM code.
 Removes a field from a model.
 
 Bear in mind that when reversed, this is actually adding a field to a model.
-The operation is reversible (apart from any data loss, which of course is
-irreversible) if the field is nullable or if it has a default value that can be
-used to populate the recreated column. If the field is not nullable and does
-not have a default value, the operation is irreversible.
+The operation is reversible (apart from any data loss, which is irreversible)
+if the field is nullable or if it has a default value that can be used to
+populate the recreated column. If the field is not nullable and does not have a
+default value, the operation is irreversible.
 
 ``AlterField``
 --------------

docs/ref/models/database-functions.txt

@@ -517,8 +517,8 @@ should typically be used instead of the more verbose equivalent,
 e.g. use ``TruncYear(...)`` rather than ``Trunc(..., kind='year')``.
 
 The subclasses are all defined as transforms, but they aren't registered with
-any fields, because the obvious lookup names are already reserved by the
-``Extract`` subclasses.
+any fields, because the lookup names are already reserved by the ``Extract``
+subclasses.
 
 Usage example::
 

docs/ref/models/fields.txt

@@ -1058,8 +1058,6 @@ directory on the filesystem. Has some special arguments, of which the first is
     whether folders in the specified location should be included.  Either this
     or :attr:`~FilePathField.allow_files` must be ``True``.
 
-Of course, these arguments can be used together.
-
 The one potential gotcha is that :attr:`~FilePathField.match` applies to the
 base filename, not the full path. So, this example::
 

docs/ref/models/instances.txt

@@ -116,8 +116,8 @@ are loaded from the database::
         super().save(*args, **kwargs)
 
 The example above shows a full ``from_db()`` implementation to clarify how that
-is done. In this case it would of course be possible to use ``super()`` call in
-the ``from_db()`` method.
+is done. In this case it would be possible to use a ``super()`` call in the
+``from_db()`` method.
 
 Refreshing objects from database
 ================================
@@ -528,8 +528,8 @@ Updating attributes based on existing fields
 --------------------------------------------
 
 Sometimes you'll need to perform a simple arithmetic task on a field, such
-as incrementing or decrementing the current value. The obvious way to
-achieve this is to do something like::
+as incrementing or decrementing the current value. One way of achieving this is
+doing the arithmetic in Python like::
 
     >>> product = Product.objects.get(name='Venezuelan Beaver Cheese')
     >>> product.number_sold += 1

docs/ref/models/querysets.txt

@@ -1135,8 +1135,8 @@ This will fetch the best pizza and all the toppings for the best pizza for each
 restaurant. This will be done in 3 database queries - one for the restaurants,
 one for the 'best pizzas', and one for the toppings.
 
-Of course, the ``best_pizza`` relationship could also be fetched using
-``select_related`` to reduce the query count to 2:
+The ``best_pizza`` relationship could also be fetched using ``select_related``
+to reduce the query count to 2::
 
     >>> Restaurant.objects.select_related('best_pizza').prefetch_related('best_pizza__toppings')
 

docs/ref/templates/language.txt

@@ -643,8 +643,7 @@ of all comments related to the current task with::
 
     {{ task.comment_set.all.count }}
 
-And of course you can easily access methods you've explicitly defined on your
-own models:
+You can also access methods you've explicitly defined on your own models:
 
 .. code-block:: python
     :caption: models.py

docs/releases/1.0-porting-guide.txt

@@ -570,7 +570,7 @@ Notes:
 
 2. In the second step you will be asked to confirm that you are prepared to
    lose the data for the application(s) in question. Say yes; we'll restore
-   this data in the third step, of course.
+   this data in the third step.
 
 3. ``DecimalField`` is not used in any of the apps shipped with Django prior
    to this change being made, so you do not need to worry about performing

docs/releases/1.10.txt

@@ -88,8 +88,8 @@ Minor features
   initially collapsed and their header will have a small "show" link.
 
 * If a user doesn't have the add permission, the ``object-tools`` block on a
-  model's changelist will now be rendered (without the add button, of course).
-  This makes it easier to add custom tools in this case.
+  model's changelist will now be rendered (without the add button). This makes
+  it easier to add custom tools in this case.
 
 * The :class:`~django.contrib.admin.models.LogEntry` model now stores change
   messages in a JSON structure so that the message can be dynamically translated

docs/releases/1.3.txt

@@ -28,11 +28,10 @@ new features from landing, including:
 * Django's testing framework now supports (and ships with a copy of)
   `the unittest2 library`_.
 
-Wherever possible, of course, new features are introduced in a
-backwards-compatible manner per :doc:`our API stability policy
-</misc/api-stability>` policy. As a result of this policy, Django 1.3
-:ref:`begins the deprecation process for some features
-<deprecated-features-1.3>`.
+Wherever possible, new features are introduced in a backwards-compatible manner
+per :doc:`our API stability policy </misc/api-stability>` policy. As a result
+of this policy, Django 1.3 :ref:`begins the deprecation process for some
+features <deprecated-features-1.3>`.
 
 .. _using Python's logging facilities: `Logging`_
 .. _easy handling of static files: `Extended static files handling`_

docs/releases/1.4.txt

@@ -723,9 +723,9 @@ Released over 10 years ago, IE6 imposes many limitations on modern Web
 development. The practical implications of this policy are that contributors
 are free to improve the admin without consideration for these limitations.
 
-Obviously, this new policy **has no impact** on sites you develop using Django.
-It only applies to the Django admin. Feel free to develop apps compatible with
-any range of browsers.
+This new policy **has no impact** on sites you develop using Django. It only
+applies to the Django admin. Feel free to develop apps compatible with any
+range of browsers.
 
 .. _YUI's A-grade: https://github.com/yui/yui3/wiki/Graded-Browser-Support
 
@@ -1302,9 +1302,9 @@ names, like ``django.contrib.*``. The expansion was performed by a
 filesystem-based implementation of ``from <package> import *``. Unfortunately,
 this can't be done reliably.
 
-This behavior was never documented. Since it is unpythonic and not obviously
-useful, it was removed in Django 1.4. If you relied on it, you must edit your
-settings file to list all your applications explicitly.
+This behavior was never documented. Since it is unpythonic, it was removed in
+Django 1.4. If you relied on it, you must edit your settings file to list all
+your applications explicitly.
 
 ``HttpRequest.raw_post_data`` renamed to ``HttpRequest.body``
 -------------------------------------------------------------

docs/releases/1.5.txt

@@ -304,9 +304,9 @@ Django 1.5 also includes several smaller improvements worth noting:
 
 * It's not required any more to have ``404.html`` and ``500.html`` templates in
   the root templates directory. Django will output some basic error messages for
-  both situations when those templates are not found. Of course, it's still
-  recommended as good practice to provide those templates in order to present
-  pretty error pages to the user.
+  both situations when those templates are not found. It's still recommended as
+  good practice to provide those templates in order to present pretty error
+  pages to the user.
 
 * :mod:`django.contrib.auth` provides a new signal that is emitted
   whenever a user fails to login successfully. See

docs/releases/1.9.txt

@@ -792,7 +792,7 @@ Consequently, the expected URLs passed to ``assertRedirects`` should generally
 no longer include the scheme and domain part of the URLs. For example,
 ``self.assertRedirects(response, 'http://testserver/some-url/')`` should be
 replaced by ``self.assertRedirects(response, '/some-url/')`` (unless the
-redirection specifically contained an absolute URL, of course).
+redirection specifically contained an absolute URL).
 
 In the rare case that you need the old behavior (discovered with an ancient
 version of Apache with ``mod_scgi`` that interprets a relative redirect as an

docs/topics/cache.txt

@@ -257,9 +257,8 @@ operations to ``cache_replica``, and all write operations to
 If you don't specify routing directions for the database cache model,
 the cache backend will use the ``default`` database.
 
-Of course, if you don't use the database cache backend, you don't need
-to worry about providing routing instructions for the database cache
-model.
+And if you don't use the database cache backend, you don't need to worry about
+providing routing instructions for the database cache model.
 
 Filesystem caching
 ------------------
@@ -325,9 +324,9 @@ order to keep them separate.
 The cache uses a least-recently-used (LRU) culling strategy.
 
 Note that each process will have its own private cache instance, which means no
-cross-process caching is possible. This obviously also means the local memory
-cache isn't particularly memory-efficient, so it's probably not a good choice
-for production environments. It's nice for development.
+cross-process caching is possible. This also means the local memory cache isn't
+particularly memory-efficient, so it's probably not a good choice for
+production environments. It's nice for development.
 
 Dummy caching (for development)
 -------------------------------

docs/topics/class-based-views/generic-display.txt

@@ -277,10 +277,9 @@ with the most recent first::
         queryset = Book.objects.order_by('-publication_date')
         context_object_name = 'book_list'
 
-That's a pretty minimal example, but it illustrates the idea nicely. Of course,
-you'll usually want to do more than just reorder objects. If you want to
-present a list of books by a particular publisher, you can use the same
-technique::
+That's a pretty minimal example, but it illustrates the idea nicely. You'll
+usually want to do more than just reorder objects. If you want to present a
+list of books by a particular publisher, you can use the same technique::
 
     from django.views.generic import ListView
     from books.models import Book
@@ -390,9 +389,8 @@ using to keep track of the last time anybody looked at that author::
         headshot = models.ImageField(upload_to='author_headshots')
         last_accessed = models.DateTimeField()
 
-The generic ``DetailView`` class, of course, wouldn't know anything about this
-field, but once again we could easily write a custom view to keep that field
-updated.
+The generic ``DetailView`` class wouldn't know anything about this field, but
+once again we could write a custom view to keep that field updated.
 
 First, we'd need to add an author detail bit in the URLconf to point to a
 custom view::

docs/topics/class-based-views/mixins.txt

@@ -174,12 +174,11 @@ specialized date-based list views.)
 Using Django's class-based view mixins
 ======================================
 
-Now we've seen how Django's generic class-based views use the provided
-mixins, let's look at other ways we can combine them. Of course we're
-still going to be combining them with either built-in class-based
-views, or other generic class-based views, but there are a range of
-rarer problems you can solve than are provided for by Django out of
-the box.
+Now we've seen how Django's generic class-based views use the provided mixins,
+let's look at other ways we can combine them. We're still going to be combining
+them with either built-in class-based views, or other generic class-based
+views, but there are a range of rarer problems you can solve than are provided
+for by Django out of the box.
 
 .. warning::
 
@@ -556,7 +555,7 @@ already know that calling :meth:`~django.views.generic.base.View.as_view()` on
 a class-based view gives us something that behaves exactly like a function
 based view, so we can do that at the point we choose between the two subviews.
 
-You can of course pass through keyword arguments to
+You can pass through keyword arguments to
 :meth:`~django.views.generic.base.View.as_view()` in the same way you
 would in your URLconf, such as if you wanted the ``AuthorInterest`` behavior
 to also appear at another URL but using a different template::

docs/topics/db/examples/one_to_one.txt

@@ -126,7 +126,7 @@ You can query the models using :ref:`lookups across relationships <lookups-that-
     >>> Restaurant.objects.exclude(place__address__contains="Ashland")
     <QuerySet [<Restaurant: Demon Dogs the restaurant>]>
 
-This of course works in reverse::
+This also works in reverse::
 
     >>> Place.objects.get(pk=1)
     <Place: Demon Dogs the place>

docs/topics/db/managers.txt

@@ -135,9 +135,9 @@ With this sample model, ``Book.objects.all()`` will return all books in the
 database, but ``Book.dahl_objects.all()`` will only return the ones written by
 Roald Dahl.
 
-Of course, because ``get_queryset()`` returns a ``QuerySet`` object, you can
-use ``filter()``, ``exclude()`` and all the other ``QuerySet`` methods on it.
-So these statements are all legal::
+Because ``get_queryset()`` returns a ``QuerySet`` object, you can use
+``filter()``, ``exclude()`` and all the other ``QuerySet`` methods on it. So
+these statements are all legal::
 
     Book.dahl_objects.all()
     Book.dahl_objects.filter(title='Matilda')

docs/topics/db/models.txt

@@ -352,8 +352,8 @@ reference <ref-foreignkey>` for details.
 
 It's suggested, but not required, that the name of a
 :class:`~django.db.models.ForeignKey` field (``manufacturer`` in the example
-above) be the name of the model, lowercase. You can, of course, call the field
-whatever you want. For example::
+above) be the name of the model, lowercase. You can call the field whatever you
+want. For example::
 
     class Car(models.Model):
         company_that_makes_it = models.ForeignKey(
@@ -952,12 +952,12 @@ extend the parent's :ref:`Meta <meta-options>` class, it can subclass it. For ex
         class Meta(CommonInfo.Meta):
             db_table = 'student_info'
 
-Django does make one adjustment to the :ref:`Meta <meta-options>` class of an abstract base
-class: before installing the :ref:`Meta <meta-options>` attribute, it sets ``abstract=False``.
-This means that children of abstract base classes don't automatically become
-abstract classes themselves. Of course, you can make an abstract base class
-that inherits from another abstract base class. You just need to remember to
-explicitly set ``abstract=True`` each time.
+Django does make one adjustment to the :ref:`Meta <meta-options>` class of an
+abstract base class: before installing the :ref:`Meta <meta-options>`
+attribute, it sets ``abstract=False``. This means that children of abstract
+base classes don't automatically become abstract classes themselves. To make
+an abstract base class that inherits from another abstract base class, you need
+to explicitly set ``abstract=True`` on the child.
 
 Some attributes won't make sense to include in the :ref:`Meta <meta-options>` class of an
 abstract base class. For example, including ``db_table`` would mean that all

docs/topics/db/queries.txt

@@ -1201,8 +1201,8 @@ query you can use the following syntax::
 If ``EntryManager`` performed default filtering in its ``get_queryset()``
 method, that filtering would apply to the ``all()`` call.
 
-Of course, specifying a custom reverse manager also enables you to call its
-custom methods::
+Specifying a custom reverse manager also enables you to call its custom
+methods::
 
     b.entry_set(manager='entries').is_published()
 

docs/topics/db/sql.txt

@@ -64,9 +64,9 @@ You could then execute custom SQL like so::
     John Smith
     Jane Jones
 
-Of course, this example isn't very exciting -- it's exactly the same as
-running ``Person.objects.all()``. However, ``raw()`` has a bunch of other
-options that make it very powerful.
+This example isn't very exciting -- it's exactly the same as running
+``Person.objects.all()``. However, ``raw()`` has a bunch of other options that
+make it very powerful.
 
 .. admonition:: Model table names
 
@@ -206,9 +206,8 @@ argument to ``raw()``::
 ``params`` is a list or dictionary of parameters. You'll use ``%s``
 placeholders in the query string for a list, or ``%(key)s``
 placeholders for a dictionary (where ``key`` is replaced by a
-dictionary key, of course), regardless of your database engine.  Such
-placeholders will be replaced with parameters from the ``params``
-argument.
+dictionary key), regardless of your database engine. Such placeholders will be
+replaced with parameters from the ``params`` argument.
 
 .. note::
 

docs/topics/db/transactions.txt

@@ -355,8 +355,8 @@ Exception handling
 
 If one on-commit function within a given transaction raises an uncaught
 exception, no later registered functions in that same transaction will run.
-This is, of course, the same behavior as if you'd executed the functions
-sequentially yourself without :func:`on_commit`.
+This is the same behavior as if you'd executed the functions sequentially
+yourself without :func:`on_commit`.
 
 Timing of execution
 -------------------

docs/topics/forms/index.txt

@@ -576,11 +576,11 @@ Complete ``<label>`` elements can also be generated using the
 Rendering form error messages
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Of course, the price of this flexibility is more work. Until now we haven't had
-to worry about how to display form errors, because that's taken care of for us.
-In this example we have had to make sure we take care of any errors for each
-field and any errors for the form as a whole. Note ``{{ form.non_field_errors
-}}`` at the top of the form and the template lookup for errors on each field.
+The price of this flexibility is a bit more work. Until now we haven't had to
+worry about how to display form errors, because that's taken care of for us. In
+this example we have had to make sure we take care of any errors for each field
+and any errors for the form as a whole. Note ``{{ form.non_field_errors }}`` at
+the top of the form and the template lookup for errors on each field.
 
 Using ``{{ form.name_of_field.errors }}`` displays a list of form errors,
 rendered as an unordered list. This might look like:

docs/topics/logging.txt

@@ -197,9 +197,9 @@ There are two other logging calls available:
 Configuring logging
 ===================
 
-Of course, it isn't enough to just put logging calls into your code.
-You also need to configure the loggers, handlers, filters and
-formatters to ensure that logging output is output in a useful way.
+It isn't enough to just put logging calls into your code. You also need to
+configure the loggers, handlers, filters, and formatters to ensure you can use
+the logging output.
 
 Python's logging library provides several techniques to configure
 logging, ranging from a programmatic interface to configuration files.

docs/topics/serialization.txt

@@ -135,8 +135,8 @@ something like::
             deserialized_object.save()
 
 In other words, the usual use is to examine the deserialized objects to make
-sure that they are "appropriate" for saving before doing so.  Of course, if you
-trust your data source you can instead save the object directly and move on.
+sure that they are "appropriate" for saving before doing so. If you trust your
+data source you can instead save the object directly and move on.
 
 The Django object itself can be inspected as ``deserialized_object.object``.
 If fields in the serialized data do not exist on a model, a

tests/custom_pk/tests.py

@@ -191,8 +191,8 @@ class CustomPKTests(TestCase):
         Business.objects.create(name='jaźń')
 
     def test_unique_pk(self):
-        # The primary key must also obviously be unique, so trying to create a
-        # new object with the same primary key will fail.
+        # The primary key must also be unique, so trying to create a new object
+        # with the same primary key will fail.
         Employee.objects.create(
             employee_code=123, first_name="Frank", last_name="Jones"
         )

tests/select_related/tests.py

@@ -60,10 +60,6 @@ class SelectRelatedTests(TestCase):
             self.assertEqual(domain.name, 'Eukaryota')
 
     def test_list_without_select_related(self):
-        """
-        select_related() also of course applies to entire lists, not just
-        items. This test verifies the expected behavior without select_related.
-        """
         with self.assertNumQueries(9):
             world = Species.objects.all()
             families = [o.genus.family.name for o in world]
@@ -75,10 +71,7 @@ class SelectRelatedTests(TestCase):
             ])
 
     def test_list_with_select_related(self):
-        """
-        select_related() also of course applies to entire lists, not just
-        items. This test verifies the expected behavior with select_related.
-        """
+        """select_related() applies to entire lists, not just items."""
         with self.assertNumQueries(1):
             world = Species.objects.all().select_related()
             families = [o.genus.family.name for o in world]

tests/timezones/tests.py

@@ -1060,14 +1060,14 @@ class LegacyFormsTests(TestCase):
     def test_form_with_non_existent_time(self):
         form = EventForm({'dt': '2011-03-27 02:30:00'})
         with timezone.override(pytz.timezone('Europe/Paris')):
-            # this is obviously a bug
+            # This is a bug.
             self.assertTrue(form.is_valid())
             self.assertEqual(form.cleaned_data['dt'], datetime.datetime(2011, 3, 27, 2, 30, 0))
 
     def test_form_with_ambiguous_time(self):
         form = EventForm({'dt': '2011-10-30 02:30:00'})
         with timezone.override(pytz.timezone('Europe/Paris')):
-            # this is obviously a bug
+            # This is a bug.
             self.assertTrue(form.is_valid())
             self.assertEqual(form.cleaned_data['dt'], datetime.datetime(2011, 10, 30, 2, 30, 0))
 

tests/utils_tests/test_safestring.py

@@ -7,8 +7,8 @@ from django.utils.safestring import SafeData, mark_safe
 
 class customescape(str):
     def __html__(self):
-        # implement specific and obviously wrong escaping
-        # in order to be able to tell for sure when it runs
+        # Implement specific and wrong escaping in order to be able to detect
+        # when it runs.
         return self.replace('<', '<<').replace('>', '>>')