Skip to content

Commit 4c1f160

Browse files
mattwang44mattwang44
committed
Deploying to gh-pages from @ 80d2f31 🚀
1 parent c035635 commit 4c1f160

File tree

568 files changed

+5975
-5928
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

568 files changed

+5975
-5928
lines changed

‎.buildinfo

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
11
# Sphinx build info version 1
22
# This file hashes the configuration used when building these files. When it is not found, a full rebuild will be done.
3-
config: a68d8f173f8c6fb415ffea49c531dde2
3+
config: 43b899311a5cc26111d9494a9d011c38
44
tags: 645f666f9bcd5a90fca523b33c5a78b7

‎_sources/c-api/file.rst.txt

Lines changed: 7 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -65,8 +65,13 @@ the :mod:`io` APIs instead.
6565
Overrides the normal behavior of :func:`io.open_code` to pass its parameter
6666
through the provided handler.
6767
68-
The handler is a function of type :c:expr:`PyObject *(\*)(PyObject *path,
69-
void *userData)`, where *path* is guaranteed to be :c:type:`PyUnicodeObject`.
68+
The handler is a function of type:
69+
70+
.. c:type:: Py_OpenCodeHookFunction
71+
72+
Equivalent of :c:expr:`PyObject *(\*)(PyObject *path,
73+
void *userData)`, where *path* is guaranteed to be
74+
:c:type:`PyUnicodeObject`.
7075
7176
The *userData* pointer is passed into the hook function. Since hook
7277
functions may be called from different runtimes, this pointer should not

‎_sources/c-api/import.rst.txt

Lines changed: 2 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -13,20 +13,8 @@ Importing Modules
1313
single: __all__ (package variable)
1414
single: modules (in module sys)
1515
16-
This is a simplified interface to :c:func:`PyImport_ImportModuleEx` below,
17-
leaving the *globals* and *locals* arguments set to ``NULL`` and *level* set
18-
to 0. When the *name*
19-
argument contains a dot (when it specifies a submodule of a package), the
20-
*fromlist* argument is set to the list ``['*']`` so that the return value is the
21-
named module rather than the top-level package containing it as would otherwise
22-
be the case. (Unfortunately, this has an additional side effect when *name* in
23-
fact specifies a subpackage instead of a submodule: the submodules specified in
24-
the package's ``__all__`` variable are loaded.) Return a new reference to the
25-
imported module, or ``NULL`` with an exception set on failure. A failing
26-
import of a module doesn't leave the module in :data:`sys.modules`.
27-
28-
This function always uses absolute imports.
29-
16+
This is a wrapper around :c:func:`PyImport_Import()` which takes a
17+
:c:expr:`const char *` as an argument instead of a :c:expr:`PyObject *`.
3018
3119
.. c:function:: PyObject* PyImport_ImportModuleNoBlock(const char *name)
3220

‎_sources/c-api/memoryview.rst.txt

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -20,6 +20,17 @@ any other object.
2020
read/write, otherwise it may be either read-only or read/write at the
2121
discretion of the exporter.
2222
23+
24+
.. c:macro:: PyBUF_READ
25+
26+
Flag to request a readonly buffer.
27+
28+
29+
.. c:macro:: PyBUF_WRITE
30+
31+
Flag to request a writable buffer.
32+
33+
2334
.. c:function:: PyObject *PyMemoryView_FromMemory(char *mem, Py_ssize_t size, int flags)
2435
2536
Create a memoryview object using *mem* as the underlying buffer.
@@ -41,6 +52,8 @@ any other object.
4152
original memory. Otherwise, a copy is made and the memoryview points to a
4253
new bytes object.
4354
55+
*buffertype* can be one of :c:macro:`PyBUF_READ` or :c:macro:`PyBUF_WRITE`.
56+
4457
4558
.. c:function:: int PyMemoryView_Check(PyObject *obj)
4659

‎_sources/c-api/object.rst.txt

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -19,6 +19,14 @@ Object Protocol
1919
to NotImplemented and return it).
2020

2121

22+
.. c:macro:: Py_PRINT_RAW
23+
24+
Flag to be used with multiple functions that print the object (like
25+
:c:func:`PyObject_Print` and :c:func:`PyFile_WriteObject`).
26+
If passed, these function would use the :func:`str` of the object
27+
instead of the :func:`repr`.
28+
29+
2230
.. c:function:: int PyObject_Print(PyObject *o, FILE *fp, int flags)
2331
2432
Print an object *o*, on file *fp*. Returns ``-1`` on error. The flags argument

‎_sources/glossary.rst.txt

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -350,7 +350,7 @@ Glossary
350350
docstring
351351
A string literal which appears as the first expression in a class,
352352
function or module. While ignored when the suite is executed, it is
353-
recognized by the compiler and put into the :attr:`__doc__` attribute
353+
recognized by the compiler and put into the :attr:`!__doc__` attribute
354354
of the enclosing class, function or module. Since it is available via
355355
introspection, it is the canonical place for documentation of the
356356
object.
@@ -1103,10 +1103,12 @@ Glossary
11031103
The :class:`collections.abc.Sequence` abstract base class
11041104
defines a much richer interface that goes beyond just
11051105
:meth:`~object.__getitem__` and :meth:`~object.__len__`, adding
1106-
:meth:`count`, :meth:`index`, :meth:`~object.__contains__`, and
1106+
:meth:`!count`, :meth:`!index`, :meth:`~object.__contains__`, and
11071107
:meth:`~object.__reversed__`. Types that implement this expanded
11081108
interface can be registered explicitly using
1109-
:func:`~abc.ABCMeta.register`.
1109+
:func:`~abc.ABCMeta.register`. For more documentation on sequence
1110+
methods generally, see
1111+
:ref:`Common Sequence Operations <typesseq-common>`.
11101112

11111113
set comprehension
11121114
A compact way to process all or part of the elements in an iterable and

‎_sources/howto/logging-cookbook.rst.txt

Lines changed: 11 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -1933,30 +1933,28 @@ This dictionary is passed to :func:`~config.dictConfig` to put the configuration
19331933

19341934
LOGGING = {
19351935
'version': 1,
1936-
'disable_existing_loggers': True,
1936+
'disable_existing_loggers': False,
19371937
'formatters': {
19381938
'verbose': {
1939-
'format': '%(levelname)s %(asctime)s %(module)s %(process)d %(thread)d %(message)s'
1939+
'format': '{levelname} {asctime} {module} {process:d} {thread:d} {message}',
1940+
'style': '{',
19401941
},
19411942
'simple': {
1942-
'format': '%(levelname)s %(message)s'
1943+
'format': '{levelname} {message}',
1944+
'style': '{',
19431945
},
19441946
},
19451947
'filters': {
19461948
'special': {
19471949
'()': 'project.logging.SpecialFilter',
19481950
'foo': 'bar',
1949-
}
1951+
},
19501952
},
19511953
'handlers': {
1952-
'null': {
1953-
'level':'DEBUG',
1954-
'class':'django.utils.log.NullHandler',
1955-
},
1956-
'console':{
1957-
'level':'DEBUG',
1958-
'class':'logging.StreamHandler',
1959-
'formatter': 'simple'
1954+
'console': {
1955+
'level': 'INFO',
1956+
'class': 'logging.StreamHandler',
1957+
'formatter': 'simple',
19601958
},
19611959
'mail_admins': {
19621960
'level': 'ERROR',
@@ -1966,9 +1964,8 @@ This dictionary is passed to :func:`~config.dictConfig` to put the configuration
19661964
},
19671965
'loggers': {
19681966
'django': {
1969-
'handlers':['null'],
1967+
'handlers': ['console'],
19701968
'propagate': True,
1971-
'level':'INFO',
19721969
},
19731970
'django.request': {
19741971
'handlers': ['mail_admins'],

‎_sources/howto/logging.rst.txt

Lines changed: 22 additions & 21 deletions
Original file line numberDiff line numberDiff line change
@@ -521,7 +521,7 @@ custom handlers) are the following configuration methods:
521521

522522
* The :meth:`~Handler.setLevel` method, just as in logger objects, specifies the
523523
lowest severity that will be dispatched to the appropriate destination. Why
524-
are there two :func:`setLevel` methods? The level set in the logger
524+
are there two :meth:`~Handler.setLevel` methods? The level set in the logger
525525
determines which severity of messages it will pass to its handlers. The level
526526
set in each handler determines which messages that handler will send on.
527527

@@ -775,29 +775,29 @@ What happens if no configuration is provided
775775

776776
If no logging configuration is provided, it is possible to have a situation
777777
where a logging event needs to be output, but no handlers can be found to
778-
output the event. The behaviour of the logging package in these
779-
circumstances is dependent on the Python version.
778+
output the event.
780779

781-
For versions of Python prior to 3.2, the behaviour is as follows:
780+
The event is output using a 'handler of last resort', stored in
781+
:data:`lastResort`. This internal handler is not associated with any
782+
logger, and acts like a :class:`~logging.StreamHandler` which writes the
783+
event description message to the current value of ``sys.stderr`` (therefore
784+
respecting any redirections which may be in effect). No formatting is
785+
done on the message - just the bare event description message is printed.
786+
The handler's level is set to ``WARNING``, so all events at this and
787+
greater severities will be output.
782788

783-
* If *logging.raiseExceptions* is ``False`` (production mode), the event is
784-
silently dropped.
789+
.. versionchanged:: 3.2
785790

786-
* If *logging.raiseExceptions* is ``True`` (development mode), a message
787-
'No handlers could be found for logger X.Y.Z' is printed once.
791+
For versions of Python prior to 3.2, the behaviour is as follows:
788792

789-
In Python 3.2 and later, the behaviour is as follows:
793+
* If :data:`raiseExceptions` is ``False`` (production mode), the event is
794+
silently dropped.
790795

791-
* The event is output using a 'handler of last resort', stored in
792-
``logging.lastResort``. This internal handler is not associated with any
793-
logger, and acts like a :class:`~logging.StreamHandler` which writes the
794-
event description message to the current value of ``sys.stderr`` (therefore
795-
respecting any redirections which may be in effect). No formatting is
796-
done on the message - just the bare event description message is printed.
797-
The handler's level is set to ``WARNING``, so all events at this and
798-
greater severities will be output.
796+
* If :data:`raiseExceptions` is ``True`` (development mode), a message
797+
'No handlers could be found for logger X.Y.Z' is printed once.
799798

800-
To obtain the pre-3.2 behaviour, ``logging.lastResort`` can be set to ``None``.
799+
To obtain the pre-3.2 behaviour,
800+
:data:`lastResort` can be set to ``None``.
801801

802802
.. _library-config:
803803

@@ -999,7 +999,7 @@ Logged messages are formatted for presentation through instances of the
999999
use with the % operator and a dictionary.
10001000

10011001
For formatting multiple messages in a batch, instances of
1002-
:class:`~handlers.BufferingFormatter` can be used. In addition to the format
1002+
:class:`BufferingFormatter` can be used. In addition to the format
10031003
string (which is applied to each message in the batch), there is provision for
10041004
header and trailer format strings.
10051005

@@ -1035,7 +1035,8 @@ checks to see if a module-level variable, :data:`raiseExceptions`, is set. If
10351035
set, a traceback is printed to :data:`sys.stderr`. If not set, the exception is
10361036
swallowed.
10371037

1038-
.. note:: The default value of :data:`raiseExceptions` is ``True``. This is
1038+
.. note::
1039+
The default value of :data:`raiseExceptions` is ``True``. This is
10391040
because during development, you typically want to be notified of any
10401041
exceptions that occur. It's advised that you set :data:`raiseExceptions` to
10411042
``False`` for production usage.
@@ -1073,7 +1074,7 @@ You can write code like this::
10731074
expensive_func2())
10741075

10751076
so that if the logger's threshold is set above ``DEBUG``, the calls to
1076-
:func:`expensive_func1` and :func:`expensive_func2` are never made.
1077+
``expensive_func1`` and ``expensive_func2`` are never made.
10771078

10781079
.. note:: In some cases, :meth:`~Logger.isEnabledFor` can itself be more
10791080
expensive than you'd like (e.g. for deeply nested loggers where an explicit

‎_sources/library/__future__.rst.txt

Lines changed: 56 additions & 42 deletions
Original file line numberDiff line numberDiff line change
@@ -8,20 +8,68 @@
88

99
--------------
1010

11-
:mod:`__future__` is a real module, and serves three purposes:
11+
Imports of the form ``from __future__ import feature`` are called
12+
:ref:`future statements <future>`. These are special-cased by the Python compiler
13+
to allow the use of new Python features in modules containing the future statement
14+
before the release in which the feature becomes standard.
15+
16+
While these future statements are given additional special meaning by the
17+
Python compiler, they are still executed like any other import statement and
18+
the :mod:`__future__` exists and is handled by the import system the same way
19+
any other Python module would be. This design serves three purposes:
1220

1321
* To avoid confusing existing tools that analyze import statements and expect to
1422
find the modules they're importing.
1523

16-
* To ensure that :ref:`future statements <future>` run under releases prior to
17-
2.1 at least yield runtime exceptions (the import of :mod:`__future__` will
18-
fail, because there was no module of that name prior to 2.1).
19-
2024
* To document when incompatible changes were introduced, and when they will be
2125
--- or were --- made mandatory. This is a form of executable documentation, and
2226
can be inspected programmatically via importing :mod:`__future__` and examining
2327
its contents.
2428

29+
* To ensure that :ref:`future statements <future>` run under releases prior to
30+
Python 2.1 at least yield runtime exceptions (the import of :mod:`__future__`
31+
will fail, because there was no module of that name prior to 2.1).
32+
33+
Module Contents
34+
---------------
35+
36+
No feature description will ever be deleted from :mod:`__future__`. Since its
37+
introduction in Python 2.1 the following features have found their way into the
38+
language using this mechanism:
39+
40+
+------------------+-------------+--------------+---------------------------------------------+
41+
| feature | optional in | mandatory in | effect |
42+
+==================+=============+==============+=============================================+
43+
| nested_scopes | 2.1.0b1 | 2.2 | :pep:`227`: |
44+
| | | | *Statically Nested Scopes* |
45+
+------------------+-------------+--------------+---------------------------------------------+
46+
| generators | 2.2.0a1 | 2.3 | :pep:`255`: |
47+
| | | | *Simple Generators* |
48+
+------------------+-------------+--------------+---------------------------------------------+
49+
| division | 2.2.0a2 | 3.0 | :pep:`238`: |
50+
| | | | *Changing the Division Operator* |
51+
+------------------+-------------+--------------+---------------------------------------------+
52+
| absolute_import | 2.5.0a1 | 3.0 | :pep:`328`: |
53+
| | | | *Imports: Multi-Line and Absolute/Relative* |
54+
+------------------+-------------+--------------+---------------------------------------------+
55+
| with_statement | 2.5.0a1 | 2.6 | :pep:`343`: |
56+
| | | | *The "with" Statement* |
57+
+------------------+-------------+--------------+---------------------------------------------+
58+
| print_function | 2.6.0a2 | 3.0 | :pep:`3105`: |
59+
| | | | *Make print a function* |
60+
+------------------+-------------+--------------+---------------------------------------------+
61+
| unicode_literals | 2.6.0a2 | 3.0 | :pep:`3112`: |
62+
| | | | *Bytes literals in Python 3000* |
63+
+------------------+-------------+--------------+---------------------------------------------+
64+
| generator_stop | 3.5.0b1 | 3.7 | :pep:`479`: |
65+
| | | | *StopIteration handling inside generators* |
66+
+------------------+-------------+--------------+---------------------------------------------+
67+
| annotations | 3.7.0b1 | TBD [1]_ | :pep:`563`: |
68+
| | | | *Postponed evaluation of annotations* |
69+
+------------------+-------------+--------------+---------------------------------------------+
70+
71+
.. XXX Adding a new entry? Remember to update simple_stmts.rst, too.
72+
2573
.. _future-classes:
2674

2775
.. class:: _Feature
@@ -65,43 +113,6 @@
65113
dynamically compiled code. This flag is stored in the :attr:`_Feature.compiler_flag`
66114
attribute on :class:`_Feature` instances.
67115

68-
No feature description will ever be deleted from :mod:`__future__`. Since its
69-
introduction in Python 2.1 the following features have found their way into the
70-
language using this mechanism:
71-
72-
+------------------+-------------+--------------+---------------------------------------------+
73-
| feature | optional in | mandatory in | effect |
74-
+==================+=============+==============+=============================================+
75-
| nested_scopes | 2.1.0b1 | 2.2 | :pep:`227`: |
76-
| | | | *Statically Nested Scopes* |
77-
+------------------+-------------+--------------+---------------------------------------------+
78-
| generators | 2.2.0a1 | 2.3 | :pep:`255`: |
79-
| | | | *Simple Generators* |
80-
+------------------+-------------+--------------+---------------------------------------------+
81-
| division | 2.2.0a2 | 3.0 | :pep:`238`: |
82-
| | | | *Changing the Division Operator* |
83-
+------------------+-------------+--------------+---------------------------------------------+
84-
| absolute_import | 2.5.0a1 | 3.0 | :pep:`328`: |
85-
| | | | *Imports: Multi-Line and Absolute/Relative* |
86-
+------------------+-------------+--------------+---------------------------------------------+
87-
| with_statement | 2.5.0a1 | 2.6 | :pep:`343`: |
88-
| | | | *The "with" Statement* |
89-
+------------------+-------------+--------------+---------------------------------------------+
90-
| print_function | 2.6.0a2 | 3.0 | :pep:`3105`: |
91-
| | | | *Make print a function* |
92-
+------------------+-------------+--------------+---------------------------------------------+
93-
| unicode_literals | 2.6.0a2 | 3.0 | :pep:`3112`: |
94-
| | | | *Bytes literals in Python 3000* |
95-
+------------------+-------------+--------------+---------------------------------------------+
96-
| generator_stop | 3.5.0b1 | 3.7 | :pep:`479`: |
97-
| | | | *StopIteration handling inside generators* |
98-
+------------------+-------------+--------------+---------------------------------------------+
99-
| annotations | 3.7.0b1 | TBD [1]_ | :pep:`563`: |
100-
| | | | *Postponed evaluation of annotations* |
101-
+------------------+-------------+--------------+---------------------------------------------+
102-
103-
.. XXX Adding a new entry? Remember to update simple_stmts.rst, too.
104-
105116
.. [1]
106117
``from __future__ import annotations`` was previously scheduled to
107118
become mandatory in Python 3.10, but the Python Steering Council
@@ -115,3 +126,6 @@ language using this mechanism:
115126

116127
:ref:`future`
117128
How the compiler treats future imports.
129+
130+
:pep:`236` - Back to the __future__
131+
The original proposal for the __future__ mechanism.

‎_sources/library/collections.abc.rst.txt

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -136,8 +136,8 @@ ABC Inherits from Abstract Methods Mi
136136
:class:`Collection` ``__len__`` ``index``, and ``count``
137137

138138
:class:`MutableSequence` :class:`Sequence` ``__getitem__``, Inherited :class:`Sequence` methods and
139-
``__setitem__``, ``append``, ``reverse``, ``extend``, ``pop``,
140-
``__delitem__``, ``remove``, and ``__iadd__``
139+
``__setitem__``, ``append``, ``clear``, ``reverse``, ``extend``,
140+
``__delitem__``, ``pop``, ``remove``, and ``__iadd__``
141141
``__len__``,
142142
``insert``
143143

0 commit comments

Comments
 (0)