django · felixxm · May 4, 2020 · May 4, 2020 · May 1, 2020
diff --git a/django/contrib/contenttypes/models.py b/django/contrib/contenttypes/models.py
@@ -104,7 +104,7 @@ def get_for_models(self, *models, for_concrete_models=True):
     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]

diff --git a/django/contrib/gis/db/backends/oracle/introspection.py b/django/contrib/gis/db/backends/oracle/introspection.py
@@ -4,9 +4,9 @@
 
 
 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'
 

diff --git a/django/db/migrations/autodetector.py b/django/db/migrations/autodetector.py
@@ -89,8 +89,8 @@ def deep_deconstruct(self, obj):
     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 @@ def generate_created_models(self):
     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):

diff --git a/django/middleware/locale.py b/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
 

diff --git a/django/template/defaulttags.py b/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::

diff --git a/docs/faq/general.txt b/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/
 

diff --git a/docs/faq/install.txt b/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?
 =======================================================

diff --git a/docs/faq/usage.txt b/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?
 ==========================================================

diff --git a/docs/howto/custom-model-fields.txt b/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

diff --git a/docs/howto/static-files/deployment.txt b/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
 -----------------------------------------------------------

diff --git a/docs/internals/contributing/bugs-and-features.txt b/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

diff --git a/docs/internals/contributing/localizing.txt b/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

diff --git a/docs/internals/contributing/triaging-tickets.txt b/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:
 

diff --git a/docs/internals/contributing/writing-code/submitting-patches.txt b/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:
 

diff --git a/docs/intro/tutorial05.txt b/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

diff --git a/docs/intro/tutorial06.txt b/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.
 

diff --git a/docs/ref/applications.txt b/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.
 

diff --git a/docs/ref/contrib/contenttypes.txt b/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)

diff --git a/docs/ref/contrib/sites.txt b/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::
 

diff --git a/docs/ref/databases.txt b/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
 =============

diff --git a/docs/ref/migration-operations.txt b/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``
 --------------

diff --git a/docs/ref/models/database-functions.txt b/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::
 

diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
@@ -1006,10 +1006,10 @@ periodically via e.g. cron).
 ``FilePathField``
 -----------------
 
-.. class:: FilePathField(path=None, match=None, recursive=False, max_length=100, **options)
+.. class:: FilePathField(path='', match=None, recursive=False, allow_files=True, allow_folders=False, max_length=100, **options)
 
 A :class:`CharField` whose choices are limited to the filenames in a certain
-directory on the filesystem. Has three special arguments, of which the first is
+directory on the filesystem. Has some special arguments, of which the first is
 **required**:
 
 .. attribute:: FilePathField.path
@@ -1058,8 +1058,6 @@ directory on the filesystem. Has three 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::
 

diff --git a/docs/ref/models/instances.txt b/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

diff --git a/docs/ref/models/querysets.txt b/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')
 

diff --git a/docs/ref/templates/language.txt b/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

diff --git a/docs/releases/1.0-porting-guide.txt b/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

diff --git a/docs/releases/1.10.txt b/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