[Python-checkins] peps: Fixup some more lists-in-blockquotes. Fixes #26914.
georg.brandl
python-checkins at python.org
Tue May 3 04:35:16 EDT 2016
https://hg.python.org/peps/rev/e7200e32b220
changeset: 6303:e7200e32b220
user: Georg Brandl <georg at python.org>
date: Tue May 03 10:35:10 2016 +0200
summary:
Fixup some more lists-in-blockquotes. Fixes #26914.
files:
pep-0318.txt | 2 +-
pep-0410.txt | 32 ++++++++++++++++----------------
pep-0422.txt | 2 +-
pep-0436.txt | 8 ++++----
pep-0446.txt | 24 ++++++++++++------------
pep-0495.txt | 40 ++++++++++++++++++++--------------------
pep-0498.txt | 8 ++++----
pep-3104.txt | 6 +++---
pep-3108.txt | 8 ++++----
pep-3127.txt | 2 +-
pep-3141.txt | 26 +++++++++++++-------------
pep-3149.txt | 4 ++--
pep-3156.txt | 14 +++++++-------
13 files changed, 88 insertions(+), 88 deletions(-)
diff --git a/pep-0318.txt b/pep-0318.txt
--- a/pep-0318.txt
+++ b/pep-0318.txt
@@ -396,7 +396,7 @@
http://mail.python.org/pipermail/python-dev/2004-August/047112.html
The next form is that the decorator syntax goes inside the method body at
-the start, in the same place that docstrings currently live:
+the start, in the same place that docstrings currently live::
def foo(arg1,arg2):
@classmethod
diff --git a/pep-0410.txt b/pep-0410.txt
--- a/pep-0410.txt
+++ b/pep-0410.txt
@@ -425,7 +425,7 @@
used: type(numerator) / type(denominator).
A variant is to use a "converter" callback to create a timestamp. Example
-creating a float timestamp:
+creating a float timestamp::
def timestamp_to_float(numerator, denominator):
return float(numerator) / float(denominator)
@@ -520,24 +520,24 @@
Python:
- * `Issue #7652: Merge C version of decimal into py3k <http://bugs.python.org/issue7652>`_ (cdecimal)
- * `Issue #11457: os.stat(): add new fields to get timestamps as Decimal objects with nanosecond resolution <http://bugs.python.org/issue11457>`_
- * `Issue #13882: PEP 410: Use decimal.Decimal type for timestamps <http://bugs.python.org/issue13882>`_
- * `[Python-Dev] Store timestamps as decimal.Decimal objects <http://mail.python.org/pipermail/python-dev/2012-January/116025.html>`_
+* `Issue #7652: Merge C version of decimal into py3k <http://bugs.python.org/issue7652>`_ (cdecimal)
+* `Issue #11457: os.stat(): add new fields to get timestamps as Decimal objects with nanosecond resolution <http://bugs.python.org/issue11457>`_
+* `Issue #13882: PEP 410: Use decimal.Decimal type for timestamps <http://bugs.python.org/issue13882>`_
+* `[Python-Dev] Store timestamps as decimal.Decimal objects <http://mail.python.org/pipermail/python-dev/2012-January/116025.html>`_
Other languages:
- * Ruby (1.9.3), the `Time class <http://ruby-doc.org/core-1.9.3/Time.html>`_
- supports picosecond (10\ :sup:`-12`)
- * .NET framework, `DateTime type <http://msdn.microsoft.com/en-us/library/system.datetime.ticks.aspx>`_:
- number of 100-nanosecond intervals that have elapsed since 12:00:00
- midnight, January 1, 0001. DateTime.Ticks uses a signed 64-bit integer.
- * Java (1.5), `System.nanoTime() <http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/System.html#nanoTime()>`_:
- wallclock with an unspecified starting point as a number of nanoseconds, use
- a signed 64 bits integer (long).
- * Perl, `Time::Hiref module <http://perldoc.perl.org/Time/HiRes.html>`_:
- use float so has the same loss of precision issue with nanosecond resolution
- than Python float timestamps
+* Ruby (1.9.3), the `Time class <http://ruby-doc.org/core-1.9.3/Time.html>`_
+ supports picosecond (10\ :sup:`-12`)
+* .NET framework, `DateTime type <http://msdn.microsoft.com/en-us/library/system.datetime.ticks.aspx>`_:
+ number of 100-nanosecond intervals that have elapsed since 12:00:00
+ midnight, January 1, 0001. DateTime.Ticks uses a signed 64-bit integer.
+* Java (1.5), `System.nanoTime() <http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/System.html#nanoTime()>`_:
+ wallclock with an unspecified starting point as a number of nanoseconds, use
+ a signed 64 bits integer (long).
+* Perl, `Time::Hiref module <http://perldoc.perl.org/Time/HiRes.html>`_:
+ use float so has the same loss of precision issue with nanosecond resolution
+ than Python float timestamps
Copyright
diff --git a/pep-0422.txt b/pep-0422.txt
--- a/pep-0422.txt
+++ b/pep-0422.txt
@@ -130,7 +130,7 @@
return cls
To simplify the cooperative multiple inheritance case, ``object`` will gain
-a default implementation of the hook that returns the class unmodified:
+a default implementation of the hook that returns the class unmodified::
class object:
def __autodecorate__(cls):
diff --git a/pep-0436.txt b/pep-0436.txt
--- a/pep-0436.txt
+++ b/pep-0436.txt
@@ -517,10 +517,10 @@
A list of strings representing acceptable Python types for this object.
There are also four strings which represent Python protocols:
- * "buffer"
- * "mapping"
- * "number"
- * "sequence"
+ * "buffer"
+ * "mapping"
+ * "number"
+ * "sequence"
``zeroes``
For converters that accept string types. The converted value should
diff --git a/pep-0446.txt b/pep-0446.txt
--- a/pep-0446.txt
+++ b/pep-0446.txt
@@ -308,18 +308,18 @@
On UNIX, new flags were added for files and sockets:
- * ``O_CLOEXEC``: available on Linux (2.6.23), FreeBSD (8.3),
- Mac OS 10.8, OpenBSD 5.0, Solaris 11, QNX, BeOS, next NetBSD release
- (6.1?). This flag is part of POSIX.1-2008.
- * ``SOCK_CLOEXEC`` flag for ``socket()`` and ``socketpair()``,
- available on Linux 2.6.27, OpenBSD 5.2, NetBSD 6.0.
- * ``fcntl()``: ``F_DUPFD_CLOEXEC`` flag, available on Linux 2.6.24,
- OpenBSD 5.0, FreeBSD 9.1, NetBSD 6.0, Solaris 11. This flag is part
- of POSIX.1-2008.
- * ``fcntl()``: ``F_DUP2FD_CLOEXEC`` flag, available on FreeBSD 9.1
- and Solaris 11.
- * ``recvmsg()``: ``MSG_CMSG_CLOEXEC``, available on Linux 2.6.23,
- NetBSD 6.0.
+* ``O_CLOEXEC``: available on Linux (2.6.23), FreeBSD (8.3),
+ Mac OS 10.8, OpenBSD 5.0, Solaris 11, QNX, BeOS, next NetBSD release
+ (6.1?). This flag is part of POSIX.1-2008.
+* ``SOCK_CLOEXEC`` flag for ``socket()`` and ``socketpair()``,
+ available on Linux 2.6.27, OpenBSD 5.2, NetBSD 6.0.
+* ``fcntl()``: ``F_DUPFD_CLOEXEC`` flag, available on Linux 2.6.24,
+ OpenBSD 5.0, FreeBSD 9.1, NetBSD 6.0, Solaris 11. This flag is part
+ of POSIX.1-2008.
+* ``fcntl()``: ``F_DUP2FD_CLOEXEC`` flag, available on FreeBSD 9.1
+ and Solaris 11.
+* ``recvmsg()``: ``MSG_CMSG_CLOEXEC``, available on Linux 2.6.23,
+ NetBSD 6.0.
On Linux older than 2.6.23, ``O_CLOEXEC`` flag is simply ignored. So
``fcntl()`` must be called to check if the file descriptor is
diff --git a/pep-0495.txt b/pep-0495.txt
--- a/pep-0495.txt
+++ b/pep-0495.txt
@@ -676,29 +676,29 @@
The following alternative names have also been considered:
- **later**
- A close contender to "fold". One author dislikes it because
- it is confusable with equally fitting "latter," but in the age
- of auto-completion everywhere this is a small consideration. A
- stronger objection may be that in the case of missing time, we
- will have ``later=True`` instance converted to an earlier time by
- ``.astimezone(timezone.utc)`` that that with ``later=False``.
- Yet again, this can be interpreted as a desirable indication that
- the original time is invalid.
+**later**
+ A close contender to "fold". One author dislikes it because
+ it is confusable with equally fitting "latter," but in the age
+ of auto-completion everywhere this is a small consideration. A
+ stronger objection may be that in the case of missing time, we
+ will have ``later=True`` instance converted to an earlier time by
+ ``.astimezone(timezone.utc)`` that that with ``later=False``.
+ Yet again, this can be interpreted as a desirable indication that
+ the original time is invalid.
- **which**
- The `original`_ placeholder name for the `localtime` function
- branch index was `independently proposed`_ for the name of the
- disambiguation attribute and received `some support`_.
+**which**
+ The `original`_ placeholder name for the `localtime` function
+ branch index was `independently proposed`_ for the name of the
+ disambiguation attribute and received `some support`_.
- **repeated**
- Did not receive any support on the mailing list.
+**repeated**
+ Did not receive any support on the mailing list.
- **ltdf**
- (Local Time Disambiguation Flag) - short and no-one will attempt
- to guess what it means without reading the docs. (This abbreviation
- was used in PEP discussions with the meaning ``ltdf=False`` is the
- earlier by those who didn't want to endorse any of the alternatives.)
+**ltdf**
+ (Local Time Disambiguation Flag) - short and no-one will attempt
+ to guess what it means without reading the docs. (This abbreviation
+ was used in PEP discussions with the meaning ``ltdf=False`` is the
+ earlier by those who didn't want to endorse any of the alternatives.)
.. _original: https://mail.python.org/pipermail/python-dev/2015-April/139099.html
.. _independently proposed: https://mail.python.org/pipermail/datetime-sig/2015-August/000479.html
diff --git a/pep-0498.txt b/pep-0498.txt
--- a/pep-0498.txt
+++ b/pep-0498.txt
@@ -616,11 +616,11 @@
recently in PEP 461 [#]_. The discussions of such a feature usually
suggest either
- - adding a method such as ``__bformat__()`` so an object can control
- how it is converted to bytes, or
+- adding a method such as ``__bformat__()`` so an object can control
+ how it is converted to bytes, or
- - having ``bytes.format()`` not be as general purpose or extensible
- as ``str.format()``.
+- having ``bytes.format()`` not be as general purpose or extensible
+ as ``str.format()``.
Both of these remain as options in the future, if such functionality
is desired.
diff --git a/pep-3104.txt b/pep-3104.txt
--- a/pep-3104.txt
+++ b/pep-3104.txt
@@ -190,9 +190,9 @@
statement similar to JavaScript's ``var``. A few possible keywords
have been proposed for this purpose:
- - ``scope x`` [4]_
- - ``var x`` [4]_ [9]_
- - ``my x`` [13]_
+- ``scope x`` [4]_
+- ``var x`` [4]_ [9]_
+- ``my x`` [13]_
In all these proposals, a declaration such as ``var x`` in a
particular scope S would cause all references to ``x`` in scopes
diff --git a/pep-3108.txt b/pep-3108.txt
--- a/pep-3108.txt
+++ b/pep-3108.txt
@@ -431,11 +431,11 @@
* videoreader
- - No longer used.
+ - No longer used.
* W
- - No longer distributed with Python.
+ - No longer distributed with Python.
.. _PyObjC: http://pyobjc.sourceforge.net/
@@ -1051,7 +1051,7 @@
* audioop/sunau/aifc
- + Audio modules where the formats are still used.
+ + Audio modules where the formats are still used.
* base64/quopri/uu
@@ -1065,7 +1065,7 @@
* linecache
- + Used internally in several places.
+ + Used internally in several places.
* nis
diff --git a/pep-3127.txt b/pep-3127.txt
--- a/pep-3127.txt
+++ b/pep-3127.txt
@@ -179,7 +179,7 @@
by eval(), and by int(token, 0). (int(token) and int(token, 2-36)
are not modified by this proposal.)
- * Under 2.6, long() is treated the same as int()
+ * Under 2.6, long() is treated the same as int()
- Formatting of integers into strings, either via the % string
operator or the new PEP 3101 advanced string formatting method.
diff --git a/pep-3141.txt b/pep-3141.txt
--- a/pep-3141.txt
+++ b/pep-3141.txt
@@ -467,19 +467,19 @@
instance of ``A``, which is a subtype of ``Complex`` (``a : A <:
Complex``), and ``b : B <: Complex``. I'll consider ``a + b``:
- 1. If A defines an __add__ which accepts b, all is well.
- 2. If A falls back to the boilerplate code, and it were to return
- a value from __add__, we'd miss the possibility that B defines
- a more intelligent __radd__, so the boilerplate should return
- NotImplemented from __add__. (Or A may not implement __add__ at
- all.)
- 3. Then B's __radd__ gets a chance. If it accepts a, all is well.
- 4. If it falls back to the boilerplate, there are no more possible
- methods to try, so this is where the default implementation
- should live.
- 5. If B <: A, Python tries B.__radd__ before A.__add__. This is
- ok, because it was implemented with knowledge of A, so it can
- handle those instances before delegating to Complex.
+1. If A defines an __add__ which accepts b, all is well.
+2. If A falls back to the boilerplate code, and it were to return
+ a value from __add__, we'd miss the possibility that B defines
+ a more intelligent __radd__, so the boilerplate should return
+ NotImplemented from __add__. (Or A may not implement __add__ at
+ all.)
+3. Then B's __radd__ gets a chance. If it accepts a, all is well.
+4. If it falls back to the boilerplate, there are no more possible
+ methods to try, so this is where the default implementation
+ should live.
+5. If B <: A, Python tries B.__radd__ before A.__add__. This is
+ ok, because it was implemented with knowledge of A, so it can
+ handle those instances before delegating to Complex.
If ``A<:Complex`` and ``B<:Real`` without sharing any other knowledge,
then the appropriate shared operation is the one involving the built
diff --git a/pep-3149.txt b/pep-3149.txt
--- a/pep-3149.txt
+++ b/pep-3149.txt
@@ -107,8 +107,8 @@
The following information *MUST* be included in the shared library
file name:
- * The Python implementation (e.g. cpython, pypy, jython, etc.)
- * The interpreter's major and minor version numbers
+* The Python implementation (e.g. cpython, pypy, jython, etc.)
+* The interpreter's major and minor version numbers
These two fields are separated by a hyphen and no dots are to appear
between the major and minor version numbers. E.g. ``cpython-32``.
diff --git a/pep-3156.txt b/pep-3156.txt
--- a/pep-3156.txt
+++ b/pep-3156.txt
@@ -1386,10 +1386,10 @@
Here is a table indicating the order and multiplicity of the basic
calls:
- 1. ``connection_made()`` -- exactly once
- 2. ``data_received()`` -- zero or more times
- 3. ``eof_received()`` -- at most once
- 4. ``connection_lost()`` -- exactly once
+1. ``connection_made()`` -- exactly once
+2. ``data_received()`` -- zero or more times
+3. ``eof_received()`` -- at most once
+4. ``connection_lost()`` -- exactly once
Calls to ``pause_writing()`` and ``resume_writing()`` occur in pairs
and only between #1 and #4. These pairs will not be nested. The
@@ -1418,9 +1418,9 @@
Here is a chart indicating the order and multiplicity of calls:
- 1. ``connection_made()`` -- exactly once
- 2. ``datagram_received()``, ``error_received()`` -- zero or more times
- 3. ``connection_lost()`` -- exactly once
+1. ``connection_made()`` -- exactly once
+2. ``datagram_received()``, ``error_received()`` -- zero or more times
+3. ``connection_lost()`` -- exactly once
Subprocess Protocol
--
Repository URL: https://hg.python.org/peps
More information about the Python-checkins
mailing list