mirror of
https://github.com/python/cpython
synced 2024-09-05 00:05:39 +00:00
bpo-33641: Convert RFC references into links. (GH-7103)
85% of them are already links.
This commit is contained in:
parent
a5c42284e6
commit
0a36ac1a09
|
@ -1652,11 +1652,11 @@ works::
|
|||
Inserting a BOM into messages sent to a SysLogHandler
|
||||
-----------------------------------------------------
|
||||
|
||||
`RFC 5424 <https://tools.ietf.org/html/rfc5424>`_ requires that a
|
||||
:rfc:`5424` requires that a
|
||||
Unicode message be sent to a syslog daemon as a set of bytes which have the
|
||||
following structure: an optional pure-ASCII component, followed by a UTF-8 Byte
|
||||
Order Mark (BOM), followed by Unicode encoded using UTF-8. (See the `relevant
|
||||
section of the specification <https://tools.ietf.org/html/rfc5424#section-6>`_.)
|
||||
Order Mark (BOM), followed by Unicode encoded using UTF-8. (See the
|
||||
:rfc:`relevant section of the specification <5424#section-6>`.)
|
||||
|
||||
In Python 3.1, code was added to
|
||||
:class:`~logging.handlers.SysLogHandler` to insert a BOM into the message, but
|
||||
|
@ -1666,7 +1666,7 @@ appear before it.
|
|||
|
||||
As this behaviour is broken, the incorrect BOM insertion code is being removed
|
||||
from Python 3.2.4 and later. However, it is not being replaced, and if you
|
||||
want to produce RFC 5424-compliant messages which include a BOM, an optional
|
||||
want to produce :rfc:`5424`-compliant messages which include a BOM, an optional
|
||||
pure-ASCII sequence before it and arbitrary Unicode after it, encoded using
|
||||
UTF-8, then you need to do the following:
|
||||
|
||||
|
@ -1689,7 +1689,7 @@ UTF-8, then you need to do the following:
|
|||
|
||||
The formatted message *will* be encoded using UTF-8 encoding by
|
||||
``SysLogHandler``. If you follow the above rules, you should be able to produce
|
||||
RFC 5424-compliant messages. If you don't, logging may not complain, but your
|
||||
:rfc:`5424`-compliant messages. If you don't, logging may not complain, but your
|
||||
messages will not be RFC 5424-compliant, and your syslog daemon may complain.
|
||||
|
||||
|
||||
|
|
|
@ -297,7 +297,7 @@ which should print something like this:
|
|||
2010-12-12 11:41:42,612 is when this event was logged.
|
||||
|
||||
The default format for date/time display (shown above) is like ISO8601 or
|
||||
RFC 3339. If you need more control over the formatting of the date/time, provide
|
||||
:rfc:`3339`. If you need more control over the formatting of the date/time, provide
|
||||
a *datefmt* argument to ``basicConfig``, as in this example::
|
||||
|
||||
import logging
|
||||
|
|
|
@ -239,7 +239,7 @@ a different URL, urllib will handle that for you). For those it can't handle,
|
|||
urlopen will raise an :exc:`HTTPError`. Typical errors include '404' (page not
|
||||
found), '403' (request forbidden), and '401' (authentication required).
|
||||
|
||||
See section 10 of RFC 2616 for a reference on all the HTTP error codes.
|
||||
See section 10 of :rfc:`2616` for a reference on all the HTTP error codes.
|
||||
|
||||
The :exc:`HTTPError` instance raised will have an integer 'code' attribute, which
|
||||
corresponds to the error sent by the server.
|
||||
|
@ -252,7 +252,7 @@ codes in the 100--299 range indicate success, you will usually only see error
|
|||
codes in the 400--599 range.
|
||||
|
||||
:attr:`http.server.BaseHTTPRequestHandler.responses` is a useful dictionary of
|
||||
response codes in that shows all the response codes used by RFC 2616. The
|
||||
response codes in that shows all the response codes used by :rfc:`2616`. The
|
||||
dictionary is reproduced here for convenience ::
|
||||
|
||||
# Table mapping response codes to messages; entries have the
|
||||
|
|
|
@ -80,7 +80,7 @@ The :mod:`binascii` module defines the following functions:
|
|||
*quotetabs* is present and true, all tabs and spaces will be encoded. If the
|
||||
optional argument *istext* is present and true, newlines are not encoded but
|
||||
trailing whitespace will be encoded. If the optional argument *header* is
|
||||
present and true, spaces will be encoded as underscores per RFC1522. If the
|
||||
present and true, spaces will be encoded as underscores per :rfc:`1522`. If the
|
||||
optional argument *header* is present and false, newline characters will be
|
||||
encoded as well; otherwise linefeed conversion might corrupt the binary data
|
||||
stream.
|
||||
|
|
|
@ -1425,7 +1425,7 @@ to the user.
|
|||
|
||||
Python supports this conversion in several ways: the ``idna`` codec performs
|
||||
conversion between Unicode and ACE, separating an input string into labels
|
||||
based on the separator characters defined in `section 3.1`_ (1) of :rfc:`3490`
|
||||
based on the separator characters defined in :rfc:`section 3.1 of RFC 3490 <3490#section-3.1>`
|
||||
and converting each label to ACE as required, and conversely separating an input
|
||||
byte string into labels based on the ``.`` separator and converting any ACE
|
||||
labels found into unicode. Furthermore, the :mod:`socket` module
|
||||
|
@ -1436,8 +1436,6 @@ parameters, such as :mod:`http.client` and :mod:`ftplib`, accept Unicode host
|
|||
names (:mod:`http.client` then also transparently sends an IDNA hostname in the
|
||||
:mailheader:`Host` field if it sends that field at all).
|
||||
|
||||
.. _section 3.1: https://tools.ietf.org/html/rfc3490#section-3.1
|
||||
|
||||
When receiving host names from the wire (such as in reverse name lookup), no
|
||||
automatic conversion to Unicode is performed: Applications wishing to present
|
||||
such host names to the user should decode them to Unicode.
|
||||
|
|
|
@ -12,7 +12,7 @@ text content and the addresses may contain unicode characters):
|
|||
.. literalinclude:: ../includes/email-simple.py
|
||||
|
||||
|
||||
Parsing RFC822 headers can easily be done by the using the classes
|
||||
Parsing :rfc:`822` headers can easily be done by the using the classes
|
||||
from the :mod:`~email.parser` module:
|
||||
|
||||
.. literalinclude:: ../includes/email-headers.py
|
||||
|
|
|
@ -295,7 +295,7 @@ followed by ``lines`` for the text version or ``binary`` for the binary version.
|
|||
If optional *rest* is given, a ``REST`` command is sent to the server, passing
|
||||
*rest* as an argument. *rest* is usually a byte offset into the requested file,
|
||||
telling the server to restart sending the file's bytes at the requested offset,
|
||||
skipping over the initial bytes. Note however that RFC 959 requires only that
|
||||
skipping over the initial bytes. Note however that :rfc:`959` requires only that
|
||||
*rest* be a string containing characters in the printable range from ASCII code
|
||||
33 to ASCII code 126. The :meth:`transfercmd` method, therefore, converts
|
||||
*rest* to a string, but no check is performed on the string's contents. If the
|
||||
|
|
|
@ -283,7 +283,7 @@ BLAKE2
|
|||
.. index::
|
||||
single: blake2b, blake2s
|
||||
|
||||
BLAKE2_ is a cryptographic hash function defined in RFC-7693_ that comes in two
|
||||
BLAKE2_ is a cryptographic hash function defined in :rfc:`7693` that comes in two
|
||||
flavors:
|
||||
|
||||
* **BLAKE2b**, optimized for 64-bit platforms and produces digests of any size
|
||||
|
@ -707,7 +707,6 @@ Domain Dedication 1.0 Universal:
|
|||
|
||||
* *Alexandr Sokolovskiy*
|
||||
|
||||
.. _RFC-7693: https://tools.ietf.org/html/rfc7693
|
||||
.. _BLAKE2: https://blake2.net
|
||||
.. _HMAC: https://en.wikipedia.org/wiki/Hash-based_message_authentication_code
|
||||
.. _BLAKE: https://131002.net/blake/
|
||||
|
|
|
@ -88,7 +88,7 @@ The following classes are provided:
|
|||
:class:`DefaultCookiePolicy` objects.
|
||||
|
||||
:class:`DefaultCookiePolicy` implements the standard accept / reject rules for
|
||||
Netscape and RFC 2965 cookies. By default, RFC 2109 cookies (ie. cookies
|
||||
Netscape and :rfc:`2965` cookies. By default, :rfc:`2109` cookies (ie. cookies
|
||||
received in a :mailheader:`Set-Cookie` header with a version cookie-attribute of
|
||||
1) are treated according to the RFC 2965 rules. However, if RFC 2965 handling
|
||||
is turned off or :attr:`rfc2109_as_netscape` is ``True``, RFC 2109 cookies are
|
||||
|
@ -100,7 +100,7 @@ The following classes are provided:
|
|||
|
||||
.. class:: Cookie()
|
||||
|
||||
This class represents Netscape, RFC 2109 and RFC 2965 cookies. It is not
|
||||
This class represents Netscape, :rfc:`2109` and :rfc:`2965` cookies. It is not
|
||||
expected that users of :mod:`http.cookiejar` construct their own :class:`Cookie`
|
||||
instances. Instead, if necessary, call :meth:`make_cookies` on a
|
||||
:class:`CookieJar` instance.
|
||||
|
@ -123,14 +123,14 @@ The following classes are provided:
|
|||
the one sketched out in ``cookie_spec.html``.
|
||||
|
||||
:rfc:`2109` - HTTP State Management Mechanism
|
||||
Obsoleted by RFC 2965. Uses :mailheader:`Set-Cookie` with version=1.
|
||||
Obsoleted by :rfc:`2965`. Uses :mailheader:`Set-Cookie` with version=1.
|
||||
|
||||
:rfc:`2965` - HTTP State Management Mechanism
|
||||
The Netscape protocol with the bugs fixed. Uses :mailheader:`Set-Cookie2` in
|
||||
place of :mailheader:`Set-Cookie`. Not widely used.
|
||||
|
||||
http://kristol.org/cookie/errata.html
|
||||
Unfinished errata to RFC 2965.
|
||||
Unfinished errata to :rfc:`2965`.
|
||||
|
||||
:rfc:`2964` - Use of HTTP State Management
|
||||
|
||||
|
@ -320,7 +320,7 @@ writing.
|
|||
|
||||
.. note::
|
||||
|
||||
This loses information about RFC 2965 cookies, and also about newer or
|
||||
This loses information about :rfc:`2965` cookies, and also about newer or
|
||||
non-standard cookie-attributes such as ``port``.
|
||||
|
||||
.. warning::
|
||||
|
@ -410,13 +410,13 @@ be assigned to.
|
|||
|
||||
.. attribute:: CookiePolicy.rfc2965
|
||||
|
||||
Implement RFC 2965 protocol.
|
||||
Implement :rfc:`2965` protocol.
|
||||
|
||||
|
||||
.. attribute:: CookiePolicy.hide_cookie2
|
||||
|
||||
Don't add :mailheader:`Cookie2` header to requests (the presence of this header
|
||||
indicates to the server that we understand RFC 2965 cookies).
|
||||
indicates to the server that we understand :rfc:`2965` cookies).
|
||||
|
||||
The most useful way to define a :class:`CookiePolicy` class is by subclassing
|
||||
from :class:`DefaultCookiePolicy` and overriding some or all of the methods
|
||||
|
@ -431,7 +431,7 @@ DefaultCookiePolicy Objects
|
|||
|
||||
Implements the standard rules for accepting and returning cookies.
|
||||
|
||||
Both RFC 2965 and Netscape cookies are covered. RFC 2965 handling is switched
|
||||
Both :rfc:`2965` and Netscape cookies are covered. RFC 2965 handling is switched
|
||||
off by default.
|
||||
|
||||
The easiest way to provide your own policy is to override this class and call
|
||||
|
@ -510,11 +510,11 @@ all be assigned to.
|
|||
|
||||
.. attribute:: DefaultCookiePolicy.rfc2109_as_netscape
|
||||
|
||||
If true, request that the :class:`CookieJar` instance downgrade RFC 2109 cookies
|
||||
If true, request that the :class:`CookieJar` instance downgrade :rfc:`2109` cookies
|
||||
(ie. cookies received in a :mailheader:`Set-Cookie` header with a version
|
||||
cookie-attribute of 1) to Netscape cookies by setting the version attribute of
|
||||
the :class:`Cookie` instance to 0. The default value is :const:`None`, in which
|
||||
case RFC 2109 cookies are downgraded if and only if RFC 2965 handling is turned
|
||||
case RFC 2109 cookies are downgraded if and only if :rfc:`2965` handling is turned
|
||||
off. Therefore, RFC 2109 cookies are downgraded by default.
|
||||
|
||||
|
||||
|
@ -527,11 +527,11 @@ General strictness switches:
|
|||
and isn't guaranteed to work!
|
||||
|
||||
|
||||
RFC 2965 protocol strictness switches:
|
||||
:rfc:`2965` protocol strictness switches:
|
||||
|
||||
.. attribute:: DefaultCookiePolicy.strict_rfc2965_unverifiable
|
||||
|
||||
Follow RFC 2965 rules on unverifiable transactions (usually, an unverifiable
|
||||
Follow :rfc:`2965` rules on unverifiable transactions (usually, an unverifiable
|
||||
transaction is one resulting from a redirect or a request for an image hosted on
|
||||
another site). If this is false, cookies are *never* blocked on the basis of
|
||||
verifiability
|
||||
|
@ -541,7 +541,7 @@ Netscape protocol strictness switches:
|
|||
|
||||
.. attribute:: DefaultCookiePolicy.strict_ns_unverifiable
|
||||
|
||||
Apply RFC 2965 rules on unverifiable transactions even to Netscape cookies.
|
||||
Apply :rfc:`2965` rules on unverifiable transactions even to Netscape cookies.
|
||||
|
||||
|
||||
.. attribute:: DefaultCookiePolicy.strict_ns_domain
|
||||
|
@ -581,7 +581,7 @@ both flags are set).
|
|||
|
||||
.. attribute:: DefaultCookiePolicy.DomainRFC2965Match
|
||||
|
||||
When setting cookies, require a full RFC 2965 domain-match.
|
||||
When setting cookies, require a full :rfc:`2965` domain-match.
|
||||
|
||||
The following attributes are provided for convenience, and are the most useful
|
||||
combinations of the above flags:
|
||||
|
@ -605,7 +605,7 @@ Cookie Objects
|
|||
standard cookie-attributes specified in the various cookie standards. The
|
||||
correspondence is not one-to-one, because there are complicated rules for
|
||||
assigning default values, because the ``max-age`` and ``expires``
|
||||
cookie-attributes contain equivalent information, and because RFC 2109 cookies
|
||||
cookie-attributes contain equivalent information, and because :rfc:`2109` cookies
|
||||
may be 'downgraded' by :mod:`http.cookiejar` from version 1 to version 0 (Netscape)
|
||||
cookies.
|
||||
|
||||
|
@ -616,8 +616,8 @@ internal consistency, so you should know what you're doing if you do that.
|
|||
|
||||
.. attribute:: Cookie.version
|
||||
|
||||
Integer or :const:`None`. Netscape cookies have :attr:`version` 0. RFC 2965 and
|
||||
RFC 2109 cookies have a ``version`` cookie-attribute of 1. However, note that
|
||||
Integer or :const:`None`. Netscape cookies have :attr:`version` 0. :rfc:`2965` and
|
||||
:rfc:`2109` cookies have a ``version`` cookie-attribute of 1. However, note that
|
||||
:mod:`http.cookiejar` may 'downgrade' RFC 2109 cookies to Netscape cookies, in which
|
||||
case :attr:`version` is 0.
|
||||
|
||||
|
@ -673,7 +673,7 @@ internal consistency, so you should know what you're doing if you do that.
|
|||
|
||||
.. attribute:: Cookie.rfc2109
|
||||
|
||||
``True`` if this cookie was received as an RFC 2109 cookie (ie. the cookie
|
||||
``True`` if this cookie was received as an :rfc:`2109` cookie (ie. the cookie
|
||||
arrived in a :mailheader:`Set-Cookie` header, and the value of the Version
|
||||
cookie-attribute in that header was 1). This attribute is provided because
|
||||
:mod:`http.cookiejar` may 'downgrade' RFC 2109 cookies to Netscape cookies, in
|
||||
|
@ -745,7 +745,7 @@ cookies (assumes Unix/Netscape convention for location of the cookies file)::
|
|||
r = opener.open("http://example.com/")
|
||||
|
||||
The next example illustrates the use of :class:`DefaultCookiePolicy`. Turn on
|
||||
RFC 2965 cookies, be more strict about domains when setting and returning
|
||||
:rfc:`2965` cookies, be more strict about domains when setting and returning
|
||||
Netscape cookies, and block some domains from setting cookies or having them
|
||||
returned::
|
||||
|
||||
|
|
|
@ -342,7 +342,7 @@ An :class:`IMAP4` instance has the following methods:
|
|||
|
||||
.. method:: IMAP4.namespace()
|
||||
|
||||
Returns IMAP namespaces as defined in RFC2342.
|
||||
Returns IMAP namespaces as defined in :rfc:`2342`.
|
||||
|
||||
|
||||
.. method:: IMAP4.noop()
|
||||
|
|
|
@ -596,7 +596,7 @@ supports sending logging messages to a remote or local Unix syslog.
|
|||
(See: :issue:`12168`.) In earlier versions, the message sent to the
|
||||
syslog daemons was always terminated with a NUL byte, because early
|
||||
versions of these daemons expected a NUL terminated message - even
|
||||
though it's not in the relevant specification (RFC 5424). More recent
|
||||
though it's not in the relevant specification (:rfc:`5424`). More recent
|
||||
versions of these daemons don't expect the NUL byte but strip it off
|
||||
if it's there, and even more recent daemons (which adhere more closely
|
||||
to RFC 5424) pass the NUL byte on as part of the message.
|
||||
|
|
|
@ -516,7 +516,7 @@ The useful mapping keys in a :class:`LogRecord` are given in the section on
|
|||
initialized with a format string for the message as a whole, as well as a
|
||||
format string for the date/time portion of a message. If no *fmt* is
|
||||
specified, ``'%(message)s'`` is used. If no *datefmt* is specified, an
|
||||
ISO8601-like (or RFC3339-like) date format is used. See the
|
||||
ISO8601-like (or :rfc:`3339`-like) date format is used. See the
|
||||
:meth:`formatTime` documentation for more details.
|
||||
|
||||
The *style* parameter can be one of '%', '{' or '$' and determines how
|
||||
|
|
|
@ -542,7 +542,7 @@ them have been superseded by newer commands in :rfc:`3977`.
|
|||
is supplied, then the returned *list* is an empty list. This is an optional NNTP
|
||||
extension, and may not be supported by all servers.
|
||||
|
||||
RFC2980 says "It is suggested that this extension be deprecated". Use
|
||||
:rfc:`2980` says "It is suggested that this extension be deprecated". Use
|
||||
:meth:`descriptions` or :meth:`description` instead.
|
||||
|
||||
|
||||
|
|
|
@ -2638,25 +2638,25 @@ with LibreSSL.
|
|||
`SSL/TLS Strong Encryption: An Introduction <https://httpd.apache.org/docs/trunk/en/ssl/ssl_intro.html>`_
|
||||
Intro from the Apache HTTP Server documentation
|
||||
|
||||
`RFC 1422: Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management <https://www.ietf.org/rfc/rfc1422>`_
|
||||
:rfc:`RFC 1422: Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management <1422>`
|
||||
Steve Kent
|
||||
|
||||
`RFC 4086: Randomness Requirements for Security <https://datatracker.ietf.org/doc/rfc4086/>`_
|
||||
:rfc:`RFC 4086: Randomness Requirements for Security <4086>`
|
||||
Donald E., Jeffrey I. Schiller
|
||||
|
||||
`RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile <https://datatracker.ietf.org/doc/rfc5280/>`_
|
||||
:rfc:`RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile <5280>`
|
||||
D. Cooper
|
||||
|
||||
`RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 <https://tools.ietf.org/html/rfc5246>`_
|
||||
:rfc:`RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 <5246>`
|
||||
T. Dierks et. al.
|
||||
|
||||
`RFC 6066: Transport Layer Security (TLS) Extensions <https://tools.ietf.org/html/rfc6066>`_
|
||||
:rfc:`RFC 6066: Transport Layer Security (TLS) Extensions <6066>`
|
||||
D. Eastlake
|
||||
|
||||
`IANA TLS: Transport Layer Security (TLS) Parameters <https://www.iana.org/assignments/tls-parameters/tls-parameters.xml>`_
|
||||
IANA
|
||||
|
||||
`RFC 7525: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) <https://tools.ietf.org/html/rfc7525>`_
|
||||
:rfc:`RFC 7525: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) <7525>`
|
||||
IETF
|
||||
|
||||
`Mozilla's Server Side TLS recommendations <https://wiki.mozilla.org/Security/Server_Side_TLS>`_
|
||||
|
|
|
@ -26,7 +26,7 @@ define which tables it uses, and what other optional parts of the ``stringprep``
|
|||
procedure are part of the profile. One example of a ``stringprep`` profile is
|
||||
``nameprep``, which is used for internationalized domain names.
|
||||
|
||||
The module :mod:`stringprep` only exposes the tables from RFC 3454. As these
|
||||
The module :mod:`stringprep` only exposes the tables from :rfc:`3454`. As these
|
||||
tables would be very large to represent them as dictionaries or lists, the
|
||||
module uses the Unicode character database internally. The module source code
|
||||
itself was generated using the ``mkstringprep.py`` utility.
|
||||
|
|
|
@ -41,8 +41,7 @@ The following exceptions are raised by :mod:`urllib.error` as appropriate:
|
|||
|
||||
.. attribute:: code
|
||||
|
||||
An HTTP status code as defined in `RFC 2616
|
||||
<http://www.faqs.org/rfcs/rfc2616.html>`_. This numeric value corresponds
|
||||
An HTTP status code as defined in :rfc:`2616`. This numeric value corresponds
|
||||
to a value found in the dictionary of codes as found in
|
||||
:attr:`http.server.BaseHTTPRequestHandler.responses`.
|
||||
|
||||
|
|
|
@ -468,7 +468,7 @@ task isn't already covered by the URL parsing functions above.
|
|||
*string* may be either a :class:`str` or a :class:`bytes`.
|
||||
|
||||
.. versionchanged:: 3.7
|
||||
Moved from RFC 2396 to RFC 3986 for quoting URL strings. "~" is now
|
||||
Moved from :rfc:`2396` to :rfc:`3986` for quoting URL strings. "~" is now
|
||||
included in the set of reserved characters.
|
||||
|
||||
The optional *encoding* and *errors* parameters specify how to deal with
|
||||
|
|
|
@ -232,7 +232,7 @@ The following classes are provided:
|
|||
containing the image.
|
||||
|
||||
*unverifiable* should indicate whether the request is unverifiable,
|
||||
as defined by RFC 2965. It defaults to ``False``. An unverifiable
|
||||
as defined by :rfc:`2965`. It defaults to ``False``. An unverifiable
|
||||
request is one whose URL the user did not have the option to
|
||||
approve. For example, if the request is for an image in an HTML
|
||||
document, and the user had no option to approve the automatic
|
||||
|
@ -504,7 +504,7 @@ request.
|
|||
.. attribute:: Request.unverifiable
|
||||
|
||||
boolean, indicates whether the request is unverifiable as defined
|
||||
by RFC 2965.
|
||||
by :rfc:`2965`.
|
||||
|
||||
.. attribute:: Request.method
|
||||
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
:mod:`uuid` --- UUID objects according to RFC 4122
|
||||
==================================================
|
||||
:mod:`uuid` --- UUID objects according to :rfc:`4122`
|
||||
=====================================================
|
||||
|
||||
.. module:: uuid
|
||||
:synopsis: UUID objects (universally unique identifiers) according to RFC 4122
|
||||
|
@ -64,7 +64,7 @@ which relays any information about the UUID's safety, using this enumeration:
|
|||
|
||||
Exactly one of *hex*, *bytes*, *bytes_le*, *fields*, or *int* must be given.
|
||||
The *version* argument is optional; if given, the resulting UUID will have its
|
||||
variant and version number set according to RFC 4122, overriding bits in the
|
||||
variant and version number set according to :rfc:`4122`, overriding bits in the
|
||||
given *hex*, *bytes*, *bytes_le*, *fields*, or *int*.
|
||||
|
||||
Comparison of UUID objects are made by way of comparing their
|
||||
|
@ -127,7 +127,7 @@ which relays any information about the UUID's safety, using this enumeration:
|
|||
|
||||
.. attribute:: UUID.urn
|
||||
|
||||
The UUID as a URN as specified in RFC 4122.
|
||||
The UUID as a URN as specified in :rfc:`4122`.
|
||||
|
||||
|
||||
.. attribute:: UUID.variant
|
||||
|
@ -158,7 +158,7 @@ The :mod:`uuid` module defines the following functions:
|
|||
runs, it may launch a separate program, which could be quite slow. If all
|
||||
attempts to obtain the hardware address fail, we choose a random 48-bit
|
||||
number with the multicast bit (least significant bit of the first octet)
|
||||
set to 1 as recommended in RFC 4122. "Hardware address" means the MAC
|
||||
set to 1 as recommended in :rfc:`4122`. "Hardware address" means the MAC
|
||||
address of a network interface. On a machine with multiple network
|
||||
interfaces, universally administered MAC addresses (i.e. where the second
|
||||
least significant bit of the first octet is *unset*) will be preferred over
|
||||
|
|
|
@ -397,7 +397,7 @@ Paste" library.
|
|||
Wrap *application* and return a new WSGI application object. The returned
|
||||
application will forward all requests to the original *application*, and will
|
||||
check that both the *application* and the server invoking it are conforming to
|
||||
the WSGI specification and to RFC 2616.
|
||||
the WSGI specification and to :rfc:`2616`.
|
||||
|
||||
Any detected nonconformance results in an :exc:`AssertionError` being raised;
|
||||
note, however, that how these errors are handled is server-dependent. For
|
||||
|
|
|
@ -328,7 +328,7 @@ Binary Objects
|
|||
Write the XML-RPC base 64 encoding of this binary item to the *out* stream object.
|
||||
|
||||
The encoded data will have newlines every 76 characters as per
|
||||
`RFC 2045 section 6.8 <https://tools.ietf.org/html/rfc2045#section-6.8>`_,
|
||||
:rfc:`RFC 2045 section 6.8 <2045#section-6.8>`,
|
||||
which was the de facto standard base64 specification when the
|
||||
XML-RPC spec was written.
|
||||
|
||||
|
|
|
@ -317,7 +317,7 @@ sophisticated and robust capabilities of its larger packages. For example:
|
|||
names, no direct knowledge or handling of XML is needed.
|
||||
|
||||
* The :mod:`email` package is a library for managing email messages, including
|
||||
MIME and other RFC 2822-based message documents. Unlike :mod:`smtplib` and
|
||||
MIME and other :rfc:`2822`-based message documents. Unlike :mod:`smtplib` and
|
||||
:mod:`poplib` which actually send and receive messages, the email package has
|
||||
a complete toolset for building or decoding complex message structures
|
||||
(including attachments) and for implementing internet encoding and header
|
||||
|
|
|
@ -998,7 +998,7 @@ complete list of changes, or look through the CVS logs for all the details.
|
|||
that lets you perform a limited number of passes through the polling loop. The
|
||||
default is still to loop forever.
|
||||
|
||||
* The :mod:`base64` module now has more complete RFC 3548 support for Base64,
|
||||
* The :mod:`base64` module now has more complete :rfc:`3548` support for Base64,
|
||||
Base32, and Base16 encoding and decoding, including optional case folding and
|
||||
optional alternative alphabets. (Contributed by Barry Warsaw.)
|
||||
|
||||
|
|
Loading…
Reference in a new issue