diff options
Diffstat (limited to 'docs/internals/contributing/writing-code')
4 files changed, 40 insertions, 36 deletions
diff --git a/docs/internals/contributing/writing-code/coding-style.txt b/docs/internals/contributing/writing-code/coding-style.txt index 125525c737..64ef6c5a51 100644 --- a/docs/internals/contributing/writing-code/coding-style.txt +++ b/docs/internals/contributing/writing-code/coding-style.txt @@ -96,13 +96,12 @@ Python style * In docstrings, follow the style of existing docstrings and :pep:`257`. -* In tests, use - :meth:`~django.test.SimpleTestCase.assertRaisesMessage` and - :meth:`~django.test.SimpleTestCase.assertWarnsMessage` - instead of :meth:`~unittest.TestCase.assertRaises` and - :meth:`~unittest.TestCase.assertWarns` so you can check the - exception or warning message. Use :meth:`~unittest.TestCase.assertRaisesRegex` - and :meth:`~unittest.TestCase.assertWarnsRegex` only if you need regular +* In tests, use :meth:`~django.test.SimpleTestCase.assertRaisesMessage` and + :meth:`~django.test.SimpleTestCase.assertWarnsMessage` instead of + :meth:`~unittest.TestCase.assertRaises` and + :meth:`~unittest.TestCase.assertWarns` so you can check the exception or + warning message. Use :meth:`~unittest.TestCase.assertRaisesRegex` and + :meth:`~unittest.TestCase.assertWarnsRegex` only if you need regular expression matching. Use :meth:`assertIs(…, True/False)<unittest.TestCase.assertIs>` for testing @@ -149,9 +148,10 @@ Imports * Put imports in these groups: future, standard library, third-party libraries, other Django components, local Django component, try/excepts. Sort lines in - each group alphabetically by the full module name. Place all ``import module`` - statements before ``from module import objects`` in each section. Use absolute - imports for other Django components and relative imports for local components. + each group alphabetically by the full module name. Place all + ``import module`` statements before ``from module import objects`` in each + section. Use absolute imports for other Django components and relative + imports for local components. * On each line, alphabetize the items with the upper case items grouped before the lowercase items. diff --git a/docs/internals/contributing/writing-code/javascript.txt b/docs/internals/contributing/writing-code/javascript.txt index 25165206f0..b61fc009b7 100644 --- a/docs/internals/contributing/writing-code/javascript.txt +++ b/docs/internals/contributing/writing-code/javascript.txt @@ -17,8 +17,8 @@ Code style for indentation, but there are some exceptions. * When naming variables, use ``camelCase`` instead of ``underscore_case``. - Different JavaScript files sometimes use a different code style. Please try to - conform to the code style of each file. + Different JavaScript files sometimes use a different code style. Please try + to conform to the code style of each file. * Use the `ESLint`_ code linter to check your code for bugs and style errors. ESLint will be run when you run the JavaScript tests. We also recommended @@ -89,8 +89,8 @@ The JavaScript tests may be run from a web browser or from the command line. Testing from a web browser ~~~~~~~~~~~~~~~~~~~~~~~~~~ -To run the tests from a web browser, open up :source:`js_tests/tests.html` in your -browser. +To run the tests from a web browser, open up :source:`js_tests/tests.html` in +your browser. To measure code coverage when running the tests, you need to view that file over HTTP. To view code coverage: diff --git a/docs/internals/contributing/writing-code/submitting-patches.txt b/docs/internals/contributing/writing-code/submitting-patches.txt index 75186111dd..d1d5a8a32d 100644 --- a/docs/internals/contributing/writing-code/submitting-patches.txt +++ b/docs/internals/contributing/writing-code/submitting-patches.txt @@ -204,9 +204,12 @@ whether to accept it. Some examples of DEPs that have been approved and fully implemented: -* `DEP 181: ORM Expressions <https://github.com/django/deps/blob/main/final/0181-orm-expressions.rst>`_ -* `DEP 182: Multiple Template Engines <https://github.com/django/deps/blob/main/final/0182-multiple-template-engines.rst>`_ -* `DEP 201: Simplified routing syntax <https://github.com/django/deps/blob/main/final/0201-simplified-routing-syntax.rst>`_ +* `DEP 181: ORM Expressions + <https://github.com/django/deps/blob/main/final/0181-orm-expressions.rst>`_ +* `DEP 182: Multiple Template Engines + <https://github.com/django/deps/blob/main/final/0182-multiple-template-engines.rst>`_ +* `DEP 201: Simplified routing syntax + <https://github.com/django/deps/blob/main/final/0201-simplified-routing-syntax.rst>`_ .. _Django Forum: https://forum.djangoproject.com/ .. _Django Enhancement Proposals: https://github.com/django/deps @@ -226,19 +229,19 @@ There are a couple of reasons that code in Django might be deprecated: no longer needs to support the older version of Python that doesn't include the library, the library will be deprecated in Django. -As the :ref:`deprecation policy<internal-release-deprecation-policy>` describes, -the first release of Django that deprecates a feature (``A.B``) should raise a -``RemovedInDjangoXXWarning`` (where XX is the Django version where the feature -will be removed) when the deprecated feature is invoked. Assuming we have good -test coverage, these warnings are converted to errors when :ref:`running the -test suite <running-unit-tests>` with warnings enabled: +As the :ref:`deprecation policy<internal-release-deprecation-policy>` +describes, the first release of Django that deprecates a feature (``A.B``) +should raise a ``RemovedInDjangoXXWarning`` (where XX is the Django version +where the feature will be removed) when the deprecated feature is invoked. +Assuming we have good test coverage, these warnings are converted to errors +when :ref:`running the test suite <running-unit-tests>` with warnings enabled: ``python -Wa runtests.py``. Thus, when adding a ``RemovedInDjangoXXWarning`` you need to eliminate or silence any warnings generated when running the tests. -The first step is to remove any use of the deprecated behavior by Django itself. -Next you can silence warnings in tests that actually test the deprecated -behavior by using the ``ignore_warnings`` decorator, either at the test or class -level: +The first step is to remove any use of the deprecated behavior by Django +itself. Next you can silence warnings in tests that actually test the +deprecated behavior by using the ``ignore_warnings`` decorator, either at the +test or class level: #) In a particular test:: @@ -305,8 +308,9 @@ Finally, there are a couple of updates to Django's documentation to make: applicable, to the current release notes (``docs/releases/A.B.txt``) under the "Features deprecated in A.B" heading. -#) Add an entry in the deprecation timeline (``docs/internals/deprecation.txt``) - under the appropriate version describing what code will be removed. +#) Add an entry in the deprecation timeline + (``docs/internals/deprecation.txt``) under the appropriate version + describing what code will be removed. Once you have completed these steps, you are finished with the deprecation. In each :term:`feature release <Feature release>`, all @@ -402,10 +406,10 @@ Bugs * Is there a proper regression test (the test should fail before the fix is applied)? -* If it's a bug that :ref:`qualifies for a backport <supported-versions-policy>` - to the stable version of Django, is there a release note in - ``docs/releases/A.B.C.txt``? Bug fixes that will be applied only to the main - branch don't need a release note. +* If it's a bug that :ref:`qualifies for a backport + <supported-versions-policy>` to the stable version of Django, is there a + release note in ``docs/releases/A.B.C.txt``? Bug fixes that will be applied + only to the main branch don't need a release note. New Features ------------ diff --git a/docs/internals/contributing/writing-code/unit-tests.txt b/docs/internals/contributing/writing-code/unit-tests.txt index 1c993f5fc6..05b2bf09c6 100644 --- a/docs/internals/contributing/writing-code/unit-tests.txt +++ b/docs/internals/contributing/writing-code/unit-tests.txt @@ -398,9 +398,9 @@ and also excludes several directories not relevant to the results Contrib apps ============ -Tests for contrib apps can be found in the :source:`tests/` directory, typically -under ``<app_name>_tests``. For example, tests for ``contrib.auth`` are located -in :source:`tests/auth_tests`. +Tests for contrib apps can be found in the :source:`tests/` directory, +typically under ``<app_name>_tests``. For example, tests for ``contrib.auth`` +are located in :source:`tests/auth_tests`. .. _troubleshooting-unit-tests: |