IntenseWebs/sphinx
3
0
Fork 0
mirror of https://github.com/sphinx-doc/sphinx.git synced 2025-02-25 18:55:22 -06:00
Code Issues Packages Projects Releases Wiki Activity

Other minor fixes.

Browse Source
This commit is contained in:
Georg Brandl
2007-08-05 12:26:55 +00:00
parent 134590216d
commit 35e26230fd
12 changed files with 115 additions and 166 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
Doc-26/library/codecs.rst
View File

@@ -734,24 +734,24 @@ Encodings and Unicode
Unicode strings are stored internally as sequences of codepoints (to be precise
as :ctype:`Py_UNICODE` arrays). Depending on the way Python is compiled (either
via :option:`--enable-unicode=ucs2` or :option:`--enable-unicode=ucs4`, with
the former being the default) :ctype:`Py_UNICODE` is either a 16-bit or 32-bit
data type. Once a Unicode object is used outside of CPU and memory, CPU
endianness and how these arrays are stored as bytes become an issue.
Transforming a unicode object into a sequence of bytes is called encoding and
recreating the unicode object from the sequence of bytes is known as decoding.
There are many different methods for how this transformation can be done (these
methods are also called encodings). The simplest method is to map the codepoints
0-255 to the bytes ``0x0``\ -\ ``0xff``. This means that a unicode object that
contains codepoints above ``U+00FF`` can't be encoded with this method (which
is called ``'latin-1'`` or ``'iso-8859-1'``). :func:`unicode.encode` will raise
a :exc:`UnicodeEncodeError` that looks like this: ``UnicodeEncodeError:
'latin-1' codec can't encode character u'\u1234' in position 3: ordinal not in
via :option:`--enable-unicode=ucs2` or :option:`--enable-unicode=ucs4`, with the
former being the default) :ctype:`Py_UNICODE` is either a 16-bit or 32-bit data
type. Once a Unicode object is used outside of CPU and memory, CPU endianness
and how these arrays are stored as bytes become an issue. Transforming a
unicode object into a sequence of bytes is called encoding and recreating the
unicode object from the sequence of bytes is known as decoding. There are many
different methods for how this transformation can be done (these methods are
also called encodings). The simplest method is to map the codepoints 0-255 to
the bytes ``0x0``-``0xff``. This means that a unicode object that contains
codepoints above ``U+00FF`` can't be encoded with this method (which is called
``'latin-1'`` or ``'iso-8859-1'``). :func:`unicode.encode` will raise a
:exc:`UnicodeEncodeError` that looks like this: ``UnicodeEncodeError: 'latin-1'
codec can't encode character u'\u1234' in position 3: ordinal not in
range(256)``.
There's another group of encodings (the so called charmap encodings) that choose
a different subset of all unicode code points and how these codepoints are
mapped to the bytes ``0x0``\ -\ ``0xff.`` To see how this is done simply open
mapped to the bytes ``0x0``-``0xff``. To see how this is done simply open
e.g. :file:`encodings/cp1252.py` (which is an encoding that is used primarily on
Windows). There's a string constant with 256 characters that shows you which
character is mapped to which byte value.
@@ -824,8 +824,9 @@ sequence: ``0xef``, ``0xbb``, ``0xbf``) is written. As it's rather improbable
that any charmap encoded file starts with these byte values (which would e.g.
map to
LATIN SMALL LETTER I WITH DIAERESIS --- RIGHT-POINTING DOUBLE ANGLE QUOTATION
MARK --- INVERTED QUESTION MARK
| LATIN SMALL LETTER I WITH DIAERESIS
| RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
| INVERTED QUESTION MARK
in iso-8859-1), this increases the probability that a utf-8-sig encoding can be
correctly guessed from the byte sequence. So here the BOM is not used to be able
@@ -1152,14 +1153,14 @@ and :mod:`stringprep`.
These RFCs together define a protocol to support non-ASCII characters in domain
names. A domain name containing non-ASCII characters (such as
"www.Alliancefrançaise.nu") is converted into an ASCII-compatible encoding (ACE,
such as "www.xn--alliancefranaise-npb.nu"). The ACE form of the domain name is
then used in all places where arbitrary characters are not allowed by the
protocol, such as DNS queries, HTTP :mailheader:`Host` fields, and so on. This
conversion is carried out in the application; if possible invisible to the user:
The application should transparently convert Unicode domain labels to IDNA on
the wire, and convert back ACE labels to Unicode before presenting them to the
user.
``www.Alliancefrançaise.nu``) is converted into an ASCII-compatible encoding
(ACE, such as ``www.xn--alliancefranaise-npb.nu``). The ACE form of the domain
name is then used in all places where arbitrary characters are not allowed by
the protocol, such as DNS queries, HTTP :mailheader:`Host` fields, and so
on. This conversion is carried out in the application; if possible invisible to
the user: The application should transparently convert Unicode domain labels to
IDNA on the wire, and convert back ACE labels to Unicode before presenting them
to the user.
Python supports this conversion in several ways: The ``idna`` codec allows to
convert between Unicode and the ACE. Furthermore, the :mod:`socket` module

4
Doc-26/library/datetime.rst
View File

@@ -473,8 +473,8 @@ Instance methods:
.. method:: date.ctime()
Return a string representing the date, for example date(2002, 12, 4).ctime() ==
'Wed Dec 4 00:00:00 2002'. ``d.ctime()`` is equivalent to
Return a string representing the date, for example ``date(2002, 12,
4).ctime() == 'Wed Dec 4 00:00:00 2002'``. ``d.ctime()`` is equivalent to
``time.ctime(time.mktime(d.timetuple()))`` on platforms where the native C
:cfunc:`ctime` function (which :func:`time.ctime` invokes, but which
:meth:`date.ctime` does not invoke) conforms to the C standard.

38
Doc-26/library/functools.rst
View File

@@ -73,25 +73,25 @@ The :mod:`functools` module defines the following function:
wrapped=wrapped, assigned=assigned, updated=updated)`` as a function decorator
when defining a wrapper function. For example::
>>> def my_decorator(f):
... @wraps(f)
... def wrapper(*args, **kwds):
... print 'Calling decorated function'
... return f(*args, **kwds)
... return wrapper
...
>>> @my_decorator
... def example():
... """Docstring"""
... print 'Called example function'
...
>>> example()
Calling decorated function
Called example function
>>> example.__name__
'example'
>>> example.__doc__
'Docstring'
>>> def my_decorator(f):
... @wraps(f)
... def wrapper(*args, **kwds):
... print 'Calling decorated function'
... return f(*args, **kwds)
... return wrapper
...
>>> @my_decorator
... def example():
... """Docstring"""
... print 'Called example function'
...
>>> example()
Calling decorated function
Called example function
>>> example.__name__
'example'
>>> example.__doc__
'Docstring'
Without the use of this decorator factory, the name of the example function
would have been ``'wrapper'``, and the docstring of the original :func:`example`

65
Doc-26/library/time.rst
View File

@@ -102,29 +102,12 @@ An explanation of some terminology and conventions is in order.
+-------+-------------------+---------------------------------+
| 8 | :attr:`tm_isdst` | 0, 1 or -1; see below |
+-------+-------------------+---------------------------------+
| - | :attr:`tm_gmtoff` | offset from UTC/GMT in seconds |
| | | east of the Prime Meridian; see |
| | | below |
+-------+-------------------+---------------------------------+
| - | :attr:`tm_zone` | time zone name; see below |
+-------+-------------------+---------------------------------+
Note that unlike the C structure, the month value is a range of 1-12, not 0-11.
A year value will be handled as described under "Year 2000 (Y2K) issues" above.
A ``-1`` argument as the daylight savings flag, passed to :func:`mktime` will
usually result in the correct daylight savings state to be filled in.
To maintain backwards compatibility, the :attr:`tm_gmtoff` and :attr:`tm_zone`
attributes are not included in the visual representation of each
:class:`struct_time`, but they can be inspected as named, read-only attributes.
Since functions such as :func:`mktime` accept either a 9-tuple or a
:class:`struct_time`, to manually construct a time with specific values of these
attributes, first construct an 11-tuple using the normal 9-tuple extended to
include values for :attr:`tm_gmtoff` and :attr:`tm_zone` as the last two
elements, then pass this tuple to the :class:`struct_time` constructor. It is
also possible to omit :attr:`tm_zone` and to provide a 10-tuple to the
:class:`struct_time` constructor.
When a tuple with an incorrect length is passed to a function expecting a
:class:`struct_time`, or having elements of the wrong type, a :exc:`TypeError`
is raised.
@@ -133,13 +116,9 @@ An explanation of some terminology and conventions is in order.
The time value sequence was changed from a tuple to a :class:`struct_time`, with
the addition of attribute names for the fields.
.. versionchanged:: 2.6
The time value sequence was extended to provide the :attr:`tm_gmtoff` and
:attr:`tm_zone` attributes as described above.
The module defines the following functions and data items:
.. data:: accept2dyear
Boolean value indicating whether two-digit year values will be accepted. This
@@ -249,25 +228,6 @@ The module defines the following functions and data items:
The earliest date for which it can generate a time is platform-dependent.
.. function:: mktimetz(t)
This function interprets times in arbitrary time zones, producing a value
indicating the number of seconds since the epoch for each time. It combines the
ability of :func:`mktime` to convert local times with the ability of
:func:`timegm` to convert GMT/UTC times, but is not constrained by the system's
current time zone, instead obtaining time zone information directly from its
argument where possible. Its argument is the :class:`struct_time` (which may
provide time zone information) or a 9-tuple (which does not, causing the
argument to be interpreted as a time in the GMT/UTC zone). It returns a
floating point number, for compatibility with :func:`time`. If the input value
cannot be represented as a valid time, either :exc:`OverflowError` or
:exc:`ValueError` will be raised (which depends on whether the invalid value is
caught by Python or the underlying C libraries). The earliest date for which it
can generate a time is platform-dependent.
.. versionadded:: 2.6
.. function:: sleep(secs)
Suspend execution for the given number of seconds. The argument may be a
@@ -371,14 +331,6 @@ The module defines the following functions and data items:
| ``%Y`` | Year with century as a decimal | |
| | number. | |
+-----------+--------------------------------+-------+
| ``%z`` | Time zone offset indicating a | |
| | positive or negative time | |
| | difference from UTC/GMT of the | |
| | form +HHMM or -HHMM, where H | |
| | represents decimal hour digits | |
| | and M represents decimal | |
| | minute digits [00,59]. | |
+-----------+--------------------------------+-------+
| ``%Z`` | Time zone name (no characters | |
| | if no time zone exists). | |
+-----------+--------------------------------+-------+
@@ -463,20 +415,6 @@ The module defines the following functions and data items:
the two calls.
.. function:: timegm(t)
This is the inverse function of :func:`gmtime`. Its argument is a
:class:`struct_time` or full 9-tuple which expresses the time in *GMT/UTC* time,
not local time as expected by :func:`mktime`. It returns a floating point
number, for compatibility with :func:`time`. If the input value cannot be
represented as a valid time, either :exc:`OverflowError` or :exc:`ValueError`
will be raised (which depends on whether the invalid value is caught by Python
or the underlying C libraries). The earliest date for which it can generate a
time is platform-dependent.
.. versionadded:: 2.6
.. data:: timezone
The offset of the local (non-DST) timezone, in seconds west of UTC (negative in
@@ -586,8 +524,7 @@ The module defines the following functions and data items:
Module :mod:`calendar`
General calendar-related functions. :func:`timegm` is the inverse of
:func:`gmtime` from this module, offering an alternative implementation of
:func:`timegm` from this module.
:func:`gmtime` from this module.
.. rubric:: Footnotes

10
Doc-26/license.rst
View File

@@ -105,7 +105,7 @@ Terms and conditions for accessing or otherwise using Python
============================================================
.. centered:: **PSF LICENSE AGREEMENT FOR PYTHON** |release|
.. centered:: PSF LICENSE AGREEMENT FOR PYTHON |release|
#. This LICENSE AGREEMENT is between the Python Software Foundation ("PSF"), and
the Individual or Organization ("Licensee") accessing and otherwise using Python
@@ -150,10 +150,10 @@ Terms and conditions for accessing or otherwise using Python
to be bound by the terms and conditions of this License Agreement.
.. centered:: **BEOPEN.COM LICENSE AGREEMENT FOR PYTHON 2.0**
.. centered:: BEOPEN.COM LICENSE AGREEMENT FOR PYTHON 2.0
.. centered:: **BEOPEN PYTHON OPEN SOURCE LICENSE AGREEMENT VERSION 1**
.. centered:: BEOPEN PYTHON OPEN SOURCE LICENSE AGREEMENT VERSION 1
#. This LICENSE AGREEMENT is between BeOpen.com ("BeOpen"), having an office at
160 Saratoga Avenue, Santa Clara, CA 95051, and the Individual or Organization
@@ -195,7 +195,7 @@ Terms and conditions for accessing or otherwise using Python
bound by the terms and conditions of this License Agreement.
.. centered:: **CNRI LICENSE AGREEMENT FOR PYTHON 1.6.1**
.. centered:: CNRI LICENSE AGREEMENT FOR PYTHON 1.6.1
#. This LICENSE AGREEMENT is between the Corporation for National Research
Initiatives, having an office at 1895 Preston White Drive, Reston, VA 20191
@@ -260,7 +260,7 @@ Terms and conditions for accessing or otherwise using Python
.. centered:: ACCEPT
.. centered:: **CWI LICENSE AGREEMENT FOR PYTHON 0.9.0 THROUGH 1.2**
.. centered:: CWI LICENSE AGREEMENT FOR PYTHON 0.9.0 THROUGH 1.2
Copyright © 1991 - 1995, Stichting Mathematisch Centrum Amsterdam, The
Netherlands. All rights reserved.

49
Doc-3k/library/codecs.rst
View File

@@ -778,24 +778,24 @@ Encodings and Unicode
Unicode strings are stored internally as sequences of codepoints (to be precise
as :ctype:`Py_UNICODE` arrays). Depending on the way Python is compiled (either
via :option:`--enable-unicode=ucs2` or :option:`--enable-unicode=ucs4`, with
the former being the default) :ctype:`Py_UNICODE` is either a 16-bit or 32-bit
data type. Once a Unicode object is used outside of CPU and memory, CPU
endianness and how these arrays are stored as bytes become an issue.
Transforming a unicode object into a sequence of bytes is called encoding and
recreating the unicode object from the sequence of bytes is known as decoding.
There are many different methods for how this transformation can be done (these
methods are also called encodings). The simplest method is to map the codepoints
0-255 to the bytes ``0x0``\ -\ ``0xff``. This means that a unicode object that
contains codepoints above ``U+00FF`` can't be encoded with this method (which
is called ``'latin-1'`` or ``'iso-8859-1'``). :func:`unicode.encode` will raise
a :exc:`UnicodeEncodeError` that looks like this: ``UnicodeEncodeError:
'latin-1' codec can't encode character u'\u1234' in position 3: ordinal not in
via :option:`--enable-unicode=ucs2` or :option:`--enable-unicode=ucs4`, with the
former being the default) :ctype:`Py_UNICODE` is either a 16-bit or 32-bit data
type. Once a Unicode object is used outside of CPU and memory, CPU endianness
and how these arrays are stored as bytes become an issue. Transforming a
unicode object into a sequence of bytes is called encoding and recreating the
unicode object from the sequence of bytes is known as decoding. There are many
different methods for how this transformation can be done (these methods are
also called encodings). The simplest method is to map the codepoints 0-255 to
the bytes ``0x0``-``0xff``. This means that a unicode object that contains
codepoints above ``U+00FF`` can't be encoded with this method (which is called
``'latin-1'`` or ``'iso-8859-1'``). :func:`unicode.encode` will raise a
:exc:`UnicodeEncodeError` that looks like this: ``UnicodeEncodeError: 'latin-1'
codec can't encode character u'\u1234' in position 3: ordinal not in
range(256)``.
There's another group of encodings (the so called charmap encodings) that choose
a different subset of all unicode code points and how these codepoints are
mapped to the bytes ``0x0``\ -\ ``0xff.`` To see how this is done simply open
mapped to the bytes ``0x0``-``0xff``. To see how this is done simply open
e.g. :file:`encodings/cp1252.py` (which is an encoding that is used primarily on
Windows). There's a string constant with 256 characters that shows you which
character is mapped to which byte value.
@@ -868,8 +868,9 @@ sequence: ``0xef``, ``0xbb``, ``0xbf``) is written. As it's rather improbable
that any charmap encoded file starts with these byte values (which would e.g.
map to
LATIN SMALL LETTER I WITH DIAERESIS --- RIGHT-POINTING DOUBLE ANGLE QUOTATION
MARK --- INVERTED QUESTION MARK
| LATIN SMALL LETTER I WITH DIAERESIS
| RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
| INVERTED QUESTION MARK
in iso-8859-1), this increases the probability that a utf-8-sig encoding can be
correctly guessed from the byte sequence. So here the BOM is not used to be able
@@ -1168,14 +1169,14 @@ and :mod:`stringprep`.
These RFCs together define a protocol to support non-ASCII characters in domain
names. A domain name containing non-ASCII characters (such as
"www.Alliancefrançaise.nu") is converted into an ASCII-compatible encoding (ACE,
such as "www.xn--alliancefranaise-npb.nu"). The ACE form of the domain name is
then used in all places where arbitrary characters are not allowed by the
protocol, such as DNS queries, HTTP :mailheader:`Host` fields, and so on. This
conversion is carried out in the application; if possible invisible to the user:
The application should transparently convert Unicode domain labels to IDNA on
the wire, and convert back ACE labels to Unicode before presenting them to the
user.
``www.Alliancefrançaise.nu``) is converted into an ASCII-compatible encoding
(ACE, such as ``www.xn--alliancefranaise-npb.nu``). The ACE form of the domain
name is then used in all places where arbitrary characters are not allowed by
the protocol, such as DNS queries, HTTP :mailheader:`Host` fields, and so
on. This conversion is carried out in the application; if possible invisible to
the user: The application should transparently convert Unicode domain labels to
IDNA on the wire, and convert back ACE labels to Unicode before presenting them
to the user.
Python supports this conversion in several ways: The ``idna`` codec allows to
convert between Unicode and the ACE. Furthermore, the :mod:`socket` module

4
Doc-3k/library/datetime.rst
View File

@@ -473,8 +473,8 @@ Instance methods:
.. method:: date.ctime()
Return a string representing the date, for example date(2002, 12, 4).ctime() ==
'Wed Dec 4 00:00:00 2002'. ``d.ctime()`` is equivalent to
Return a string representing the date, for example ``date(2002, 12,
4).ctime() == 'Wed Dec 4 00:00:00 2002'``. ``d.ctime()`` is equivalent to
``time.ctime(time.mktime(d.timetuple()))`` on platforms where the native C
:cfunc:`ctime` function (which :func:`time.ctime` invokes, but which
:meth:`date.ctime` does not invoke) conforms to the C standard.

38
Doc-3k/library/functools.rst
View File

@@ -85,25 +85,25 @@ The :mod:`functools` module defines the following function:
wrapped=wrapped, assigned=assigned, updated=updated)`` as a function decorator
when defining a wrapper function. For example::
>>> def my_decorator(f):
... @wraps(f)
... def wrapper(*args, **kwds):
... print 'Calling decorated function'
... return f(*args, **kwds)
... return wrapper
...
>>> @my_decorator
... def example():
... """Docstring"""
... print 'Called example function'
...
>>> example()
Calling decorated function
Called example function
>>> example.__name__
'example'
>>> example.__doc__
'Docstring'
>>> def my_decorator(f):
... @wraps(f)
... def wrapper(*args, **kwds):
... print 'Calling decorated function'
... return f(*args, **kwds)
... return wrapper
...
>>> @my_decorator
... def example():
... """Docstring"""
... print 'Called example function'
...
>>> example()
Calling decorated function
Called example function
>>> example.__name__
'example'
>>> example.__doc__
'Docstring'
Without the use of this decorator factory, the name of the example function
would have been ``'wrapper'``, and the docstring of the original :func:`example`

10
Doc-3k/license.rst
View File

@@ -105,7 +105,7 @@ Terms and conditions for accessing or otherwise using Python
============================================================
.. centered:: **PSF LICENSE AGREEMENT FOR PYTHON** |release|
.. centered:: PSF LICENSE AGREEMENT FOR PYTHON |release|
#. This LICENSE AGREEMENT is between the Python Software Foundation ("PSF"), and
the Individual or Organization ("Licensee") accessing and otherwise using Python
@@ -150,10 +150,10 @@ Terms and conditions for accessing or otherwise using Python
to be bound by the terms and conditions of this License Agreement.
.. centered:: **BEOPEN.COM LICENSE AGREEMENT FOR PYTHON 2.0**
.. centered:: BEOPEN.COM LICENSE AGREEMENT FOR PYTHON 2.0
.. centered:: **BEOPEN PYTHON OPEN SOURCE LICENSE AGREEMENT VERSION 1**
.. centered:: BEOPEN PYTHON OPEN SOURCE LICENSE AGREEMENT VERSION 1
#. This LICENSE AGREEMENT is between BeOpen.com ("BeOpen"), having an office at
160 Saratoga Avenue, Santa Clara, CA 95051, and the Individual or Organization
@@ -195,7 +195,7 @@ Terms and conditions for accessing or otherwise using Python
bound by the terms and conditions of this License Agreement.
.. centered:: **CNRI LICENSE AGREEMENT FOR PYTHON 1.6.1**
.. centered:: CNRI LICENSE AGREEMENT FOR PYTHON 1.6.1
#. This LICENSE AGREEMENT is between the Corporation for National Research
Initiatives, having an office at 1895 Preston White Drive, Reston, VA 20191
@@ -260,7 +260,7 @@ Terms and conditions for accessing or otherwise using Python
.. centered:: ACCEPT
.. centered:: **CWI LICENSE AGREEMENT FOR PYTHON 0.9.0 THROUGH 1.2**
.. centered:: CWI LICENSE AGREEMENT FOR PYTHON 0.9.0 THROUGH 1.2
Copyright © 1991 - 1995, Stichting Mathematisch Centrum Amsterdam, The
Netherlands. All rights reserved.

5
sphinx/style/default.css
View File

@@ -638,6 +638,11 @@ p.admonition-title:after {
content: ":";
}
div.body p.centered {
text-align: center;
margin-top: 25px;
}
table.docutils {
border: 0;
}

5
sphinx/style/traditional.css
View File

@@ -547,6 +547,11 @@ p.admonition-title:after {
content: ":";
}
div.body p.centered {
text-align: center;
margin-top: 25px;
}
table.docutils {
border: 0;
}

4
sphinx/writer.py
View File

@@ -174,9 +174,9 @@ class HTMLTranslator(BaseTranslator):
pass
def visit_centered(self, node):
self.body.append(self.starttag(node, 'center') + '<strong>')
self.body.append(self.starttag(node, 'p', CLASS="centered") + '<strong>')
def depart_centered(self, node):
self.body.append('</strong></center>')
self.body.append('</strong></p>')
def visit_compact_paragraph(self, node):
pass