From d17b380653da5f95885ce53468fe7aac60672841 Mon Sep 17 00:00:00 2001 From: Adam Johnson Date: Fri, 1 May 2020 13:37:21 +0100 Subject: [PATCH] Refs #30573 -- Rephrased "Of Course" and "Obvious(ly)" in documentation and comments. --- django/contrib/contenttypes/models.py | 2 +- .../gis/db/backends/oracle/introspection.py | 6 +++--- django/db/migrations/autodetector.py | 9 ++++----- django/middleware/locale.py | 2 +- django/template/defaulttags.py | 2 +- docs/faq/general.txt | 15 +++++++-------- docs/faq/install.txt | 4 ++-- docs/faq/usage.txt | 2 +- docs/howto/custom-model-fields.txt | 12 ++++++------ docs/howto/static-files/deployment.txt | 6 +++--- .../internals/contributing/bugs-and-features.txt | 7 +++---- docs/internals/contributing/localizing.txt | 5 ++--- docs/internals/contributing/triaging-tickets.txt | 4 ++-- .../writing-code/submitting-patches.txt | 7 +++---- docs/intro/tutorial05.txt | 6 +++--- docs/intro/tutorial06.txt | 8 ++++---- docs/ref/applications.txt | 5 ++--- docs/ref/contrib/contenttypes.txt | 4 ++-- docs/ref/contrib/sites.txt | 3 +-- docs/ref/databases.txt | 4 ++-- docs/ref/migration-operations.txt | 8 ++++---- docs/ref/models/database-functions.txt | 4 ++-- docs/ref/models/fields.txt | 2 -- docs/ref/models/instances.txt | 8 ++++---- docs/ref/models/querysets.txt | 4 ++-- docs/ref/templates/language.txt | 3 +-- docs/releases/1.0-porting-guide.txt | 2 +- docs/releases/1.10.txt | 4 ++-- docs/releases/1.3.txt | 9 ++++----- docs/releases/1.4.txt | 12 ++++++------ docs/releases/1.5.txt | 6 +++--- docs/releases/1.9.txt | 2 +- docs/topics/cache.txt | 11 +++++------ .../topics/class-based-views/generic-display.txt | 12 +++++------- docs/topics/class-based-views/mixins.txt | 13 ++++++------- docs/topics/db/examples/one_to_one.txt | 2 +- docs/topics/db/managers.txt | 6 +++--- docs/topics/db/models.txt | 16 ++++++++-------- docs/topics/db/queries.txt | 4 ++-- docs/topics/db/sql.txt | 11 +++++------ docs/topics/db/transactions.txt | 4 ++-- docs/topics/forms/index.txt | 10 +++++----- docs/topics/logging.txt | 6 +++--- docs/topics/serialization.txt | 4 ++-- tests/custom_pk/tests.py | 4 ++-- tests/select_related/tests.py | 9 +-------- tests/timezones/tests.py | 4 ++-- tests/utils_tests/test_safestring.py | 4 ++-- 48 files changed, 137 insertions(+), 160 deletions(-) diff --git a/django/contrib/contenttypes/models.py b/django/contrib/contenttypes/models.py index 704d79826d..edc488728a 100644 --- a/django/contrib/contenttypes/models.py +++ b/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] diff --git a/django/contrib/gis/db/backends/oracle/introspection.py b/django/contrib/gis/db/backends/oracle/introspection.py index 5e71c84fdd..f97f0e1446 100644 --- a/django/contrib/gis/db/backends/oracle/introspection.py +++ b/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' diff --git a/django/db/migrations/autodetector.py b/django/db/migrations/autodetector.py index 89b95b19a9..0d72a3226e 100644 --- a/django/db/migrations/autodetector.py +++ b/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): diff --git a/django/middleware/locale.py b/django/middleware/locale.py index 2399debf6e..e4f3537320 100644 --- 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 index 7ab21b320e..8501330c4b 100644 --- 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 index 9dc4d1b0d4..128c0d9288 100644 --- 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. does -- 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 index 45f3a79efc..2cbbb83b7f 100644 --- 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 index 60261508df..0145a580fd 100644 --- 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 index 8a8da037f3..c31a5dbc4f 100644 --- 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 index 1b4135e037..c1421d8244 100644 --- a/docs/howto/static-files/deployment.txt +++ b/docs/howto/static-files/deployment.txt @@ -21,9 +21,9 @@ manually or the :func:`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 index da4ee20a15..d782f8000d 100644 --- 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 index a2f45b2b46..8fb6fa5b08 100644 --- 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 index 10098cbfca..950c03e4f4 100644 --- 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 index 5ea265c55b..45b2b9bdc4 100644 --- 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 index b056d53bea..046abb8124 100644 --- 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 index e81f6cdf0c..be69f5e162 100644 --- 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 index 17b5615400..d1a242163f 100644 --- 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 index 43502c2e2e..66dbfe45ef 100644 --- 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') , ]> -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 index 442799ae81..11abed3231 100644 --- 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 index b594618bb1..391797d412 100644 --- 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 index 02afe67b51..a6b42bdc99 100644 --- 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 index d0043857cd..b702085e77 100644 --- 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 index 036a2c996e..e266715a36 100644 --- a/docs/ref/models/fields.txt +++ b/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:: diff --git a/docs/ref/models/instances.txt b/docs/ref/models/instances.txt index 43ed5934ca..06c63eba04 100644 --- 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 index c51c4dd43a..cd22b03418 100644 --- 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 index 5d4c8f147b..852d78a187 100644 --- 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 index 8ea7945ad3..7e7a7ad0f6 100644 --- 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 index a5193179ac..576a4c85d1 100644 --- 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 diff --git a/docs/releases/1.3.txt b/docs/releases/1.3.txt index 7e02bcd0a5..38e84f936f 100644 --- a/docs/releases/1.3.txt +++ b/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 -` policy. As a result of this policy, Django 1.3 -:ref:`begins the deprecation process for some features -`. +Wherever possible, new features are introduced in a backwards-compatible manner +per :doc:`our API stability policy ` policy. As a result +of this policy, Django 1.3 :ref:`begins the deprecation process for some +features `. .. _using Python's logging facilities: `Logging`_ .. _easy handling of static files: `Extended static files handling`_ diff --git a/docs/releases/1.4.txt b/docs/releases/1.4.txt index 6f74bfa660..9a802ac370 100644 --- a/docs/releases/1.4.txt +++ b/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 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`` ------------------------------------------------------------- diff --git a/docs/releases/1.5.txt b/docs/releases/1.5.txt index 44d567931a..c647464432 100644 --- a/docs/releases/1.5.txt +++ b/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 diff --git a/docs/releases/1.9.txt b/docs/releases/1.9.txt index 54c02a2762..171d427619 100644 --- a/docs/releases/1.9.txt +++ b/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 diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt index bc6b96ecfe..330b40dad7 100644 --- a/docs/topics/cache.txt +++ b/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) ------------------------------- diff --git a/docs/topics/class-based-views/generic-display.txt b/docs/topics/class-based-views/generic-display.txt index a24e8c5494..66590849a0 100644 --- a/docs/topics/class-based-views/generic-display.txt +++ b/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:: diff --git a/docs/topics/class-based-views/mixins.txt b/docs/topics/class-based-views/mixins.txt index 7ec8cc915e..02594b952a 100644 --- a/docs/topics/class-based-views/mixins.txt +++ b/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:: diff --git a/docs/topics/db/examples/one_to_one.txt b/docs/topics/db/examples/one_to_one.txt index 636b6ab91f..95be1cf724 100644 --- a/docs/topics/db/examples/one_to_one.txt +++ b/docs/topics/db/examples/one_to_one.txt @@ -126,7 +126,7 @@ You can query the models using :ref:`lookups across relationships >> Restaurant.objects.exclude(place__address__contains="Ashland") ]> -This of course works in reverse:: +This also works in reverse:: >>> Place.objects.get(pk=1) diff --git a/docs/topics/db/managers.txt b/docs/topics/db/managers.txt index ec29d7b639..08a1bc4505 100644 --- a/docs/topics/db/managers.txt +++ b/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') diff --git a/docs/topics/db/models.txt b/docs/topics/db/models.txt index dd9fc3aa54..e568f37f58 100644 --- a/docs/topics/db/models.txt +++ b/docs/topics/db/models.txt @@ -352,8 +352,8 @@ reference ` 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 ` class, it can subclass it. For ex class Meta(CommonInfo.Meta): db_table = 'student_info' -Django does make one adjustment to the :ref:`Meta ` class of an abstract base -class: before installing the :ref:`Meta ` 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 ` class of an +abstract base class: before installing the :ref:`Meta ` +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 ` class of an abstract base class. For example, including ``db_table`` would mean that all diff --git a/docs/topics/db/queries.txt b/docs/topics/db/queries.txt index 415d229b02..c0d0f2b3e3 100644 --- a/docs/topics/db/queries.txt +++ b/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() diff --git a/docs/topics/db/sql.txt b/docs/topics/db/sql.txt index 3fabf6607e..c7224c78b0 100644 --- a/docs/topics/db/sql.txt +++ b/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:: diff --git a/docs/topics/db/transactions.txt b/docs/topics/db/transactions.txt index cebec3d7d1..40a36e777d 100644 --- a/docs/topics/db/transactions.txt +++ b/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 ------------------- diff --git a/docs/topics/forms/index.txt b/docs/topics/forms/index.txt index 7210868625..e55b6d7bf2 100644 --- a/docs/topics/forms/index.txt +++ b/docs/topics/forms/index.txt @@ -576,11 +576,11 @@ Complete ``