[Python-checkins] peps: Fix lists-in-blockquotes in 3xxx PEPs. Ref: #26914
georg.brandl
python-checkins at python.org
Tue May 3 03:52:27 EDT 2016
https://hg.python.org/peps/rev/d420d6fe349f
changeset: 6301:d420d6fe349f
user: Georg Brandl <georg at python.org>
date: Tue May 03 09:51:54 2016 +0200
summary:
Fix lists-in-blockquotes in 3xxx PEPs. Ref: #26914
files:
pep-3103.txt | 10 +-
pep-3104.txt | 40 ++--
pep-3108.txt | 304 +++++++++++++++++++-------------------
pep-3121.txt | 8 +-
pep-3127.txt | 76 ++++----
pep-3131.txt | 6 +-
pep-3137.txt | 66 ++++----
pep-3147.txt | 4 +-
pep-3149.txt | 20 +-
pep-3150.txt | 38 ++--
10 files changed, 284 insertions(+), 288 deletions(-)
diff --git a/pep-3103.txt b/pep-3103.txt
--- a/pep-3103.txt
+++ b/pep-3103.txt
@@ -567,11 +567,11 @@
inside a function. There are a few pragmatic choices for how to treat
a switch outside a function:
- (a) Disallow it.
- (b) Translate it into an if/elif chain.
- (c) Allow only compile-time constant expressions.
- (d) Compute the dispatch dict each time the switch is reached.
- (e) Like (b) but tests that all expressions evaluated are hashable.
+(a) Disallow it.
+(b) Translate it into an if/elif chain.
+(c) Allow only compile-time constant expressions.
+(d) Compute the dispatch dict each time the switch is reached.
+(e) Like (b) but tests that all expressions evaluated are hashable.
Of these, (a) seems too restrictive: it's uniformly worse than (c);
and (d) has poor performance for little or no benefits compared to
diff --git a/pep-3104.txt b/pep-3104.txt
--- a/pep-3104.txt
+++ b/pep-3104.txt
@@ -295,26 +295,26 @@
Many spellings have been suggested for such a declaration:
- - ``scoped x`` [1]_
- - ``global x in f`` [3]_ (explicitly specify which scope)
- - ``free x`` [5]_
- - ``outer x`` [6]_
- - ``use x`` [9]_
- - ``global x`` [10]_ (change the meaning of ``global``)
- - ``nonlocal x`` [11]_
- - ``global x outer`` [18]_
- - ``global in x`` [18]_
- - ``not global x`` [18]_
- - ``extern x`` [20]_
- - ``ref x`` [22]_
- - ``refer x`` [22]_
- - ``share x`` [22]_
- - ``sharing x`` [22]_
- - ``common x`` [22]_
- - ``using x`` [22]_
- - ``borrow x`` [22]_
- - ``reuse x`` [23]_
- - ``scope f x`` [25]_ (explicitly specify which scope)
+- ``scoped x`` [1]_
+- ``global x in f`` [3]_ (explicitly specify which scope)
+- ``free x`` [5]_
+- ``outer x`` [6]_
+- ``use x`` [9]_
+- ``global x`` [10]_ (change the meaning of ``global``)
+- ``nonlocal x`` [11]_
+- ``global x outer`` [18]_
+- ``global in x`` [18]_
+- ``not global x`` [18]_
+- ``extern x`` [20]_
+- ``ref x`` [22]_
+- ``refer x`` [22]_
+- ``share x`` [22]_
+- ``sharing x`` [22]_
+- ``common x`` [22]_
+- ``using x`` [22]_
+- ``borrow x`` [22]_
+- ``reuse x`` [23]_
+- ``scope f x`` [25]_ (explicitly specify which scope)
The most commonly discussed choices appear to be ``outer``,
``global``, and ``nonlocal``. ``outer`` is already used as both a
diff --git a/pep-3108.txt b/pep-3108.txt
--- a/pep-3108.txt
+++ b/pep-3108.txt
@@ -70,56 +70,56 @@
* cfmfile
- + Documented as deprecated since Python 2.4 without an explicit
- reason.
+ + Documented as deprecated since Python 2.4 without an explicit
+ reason.
* cl
- + Documented as obsolete since Python 2.0 or earlier.
- + Interface to SGI hardware.
+ + Documented as obsolete since Python 2.0 or earlier.
+ + Interface to SGI hardware.
* md5
- + Supplanted by the ``hashlib`` module.
+ + Supplanted by the ``hashlib`` module.
* mimetools
- + Documented as obsolete in a previous version.
- + Supplanted by the ``email`` package.
+ + Documented as obsolete in a previous version.
+ + Supplanted by the ``email`` package.
* MimeWriter
- + Supplanted by the ``email`` package.
+ + Supplanted by the ``email`` package.
* mimify
- + Supplanted by the ``email`` package.
+ + Supplanted by the ``email`` package.
* multifile
- + Supplanted by the ``email`` package.
+ + Supplanted by the ``email`` package.
* posixfile
- + Locking is better done by ``fcntl.lockf()``.
+ + Locking is better done by ``fcntl.lockf()``.
* rfc822
- + Supplanted by the ``email`` package.
+ + Supplanted by the ``email`` package.
* sha
- + Supplanted by the ``hashlib`` package.
+ + Supplanted by the ``hashlib`` package.
* sv
- + Documented as obsolete since Python 2.0 or earlier.
- + Interface to obsolete SGI Indigo hardware.
+ + Documented as obsolete since Python 2.0 or earlier.
+ + Interface to obsolete SGI Indigo hardware.
* timing
- + Documented as obsolete since Python 2.0 or earlier.
- + ``time.clock()`` gives better time resolution.
+ + Documented as obsolete since Python 2.0 or earlier.
+ + ``time.clock()`` gives better time resolution.
Platform-specific with minimal use [done]
@@ -136,120 +136,121 @@
for the specified platforms will also be removed.
IRIX
-///////////
+////
+
The IRIX operating system is no longer produced [#irix-retirement]_.
Removing all modules from the plat-irix[56] directory has been deemed
reasonable because of this fact.
- + AL/al
++ AL/al
- - Provides sound support on Indy and Indigo workstations.
- - Both workstations are no longer available.
- - Code has not been uniquely edited in three years.
+ - Provides sound support on Indy and Indigo workstations.
+ - Both workstations are no longer available.
+ - Code has not been uniquely edited in three years.
- + cd/CD
++ cd/CD
- - CD drive control for SGI systems.
- - SGI no longer sells machines with IRIX on them.
- - Code has not been uniquely edited in 14 years.
+ - CD drive control for SGI systems.
+ - SGI no longer sells machines with IRIX on them.
+ - Code has not been uniquely edited in 14 years.
- + cddb
++ cddb
- - Undocumented.
+ - Undocumented.
- + cdplayer
++ cdplayer
- - Undocumented.
+ - Undocumented.
- + cl/CL/CL_old
++ cl/CL/CL_old
- - Compression library for SGI systems.
- - SGI no longer sells machines with IRIX on them.
- - Code has not been uniquely edited in 14 years.
+ - Compression library for SGI systems.
+ - SGI no longer sells machines with IRIX on them.
+ - Code has not been uniquely edited in 14 years.
- + DEVICE/GL/gl/cgen/cgensuport
++ DEVICE/GL/gl/cgen/cgensuport
- - GL access, which is the predecessor to OpenGL.
- - Has not been edited in at least eight years.
- - Third-party libraries provide better support (PyOpenGL [#pyopengl]_).
+ - GL access, which is the predecessor to OpenGL.
+ - Has not been edited in at least eight years.
+ - Third-party libraries provide better support (PyOpenGL [#pyopengl]_).
- + ERRNO
++ ERRNO
- - Undocumented.
+ - Undocumented.
- + FILE
++ FILE
- - Undocumented.
+ - Undocumented.
- + FL/fl/flp
++ FL/fl/flp
- - Wrapper for the FORMS library [#irix-forms]_
- - FORMS has not been edited in 12 years.
- - Library is not widely used.
- - First eight hits on Google are for Python docs for fl.
+ - Wrapper for the FORMS library [#irix-forms]_
+ - FORMS has not been edited in 12 years.
+ - Library is not widely used.
+ - First eight hits on Google are for Python docs for fl.
- + fm
++ fm
- - Wrapper to the IRIS Font Manager library.
- - Only available on SGI machines which no longer come with IRIX.
+ - Wrapper to the IRIS Font Manager library.
+ - Only available on SGI machines which no longer come with IRIX.
- + GET
++ GET
- - Undocumented.
+ - Undocumented.
- + GLWS
++ GLWS
- - Undocumented.
+ - Undocumented.
- + imgfile
++ imgfile
- - Wrapper for SGI libimage library for imglib image files
- (``.rgb`` files).
- - Python Imaging Library provdes read-only support [#pil]_.
- - Not uniquely edited in 13 years.
+ - Wrapper for SGI libimage library for imglib image files
+ (``.rgb`` files).
+ - Python Imaging Library provdes read-only support [#pil]_.
+ - Not uniquely edited in 13 years.
- + IN
++ IN
- - Undocumented.
+ - Undocumented.
- + IOCTL
++ IOCTL
- - Undocumented.
+ - Undocumented.
- + jpeg
++ jpeg
- - Wrapper for JPEG (de)compressor.
- - Code not uniquely edited in nine years.
- - Third-party libraries provide better support
- (Python Imaging Library [#pil]_).
+ - Wrapper for JPEG (de)compressor.
+ - Code not uniquely edited in nine years.
+ - Third-party libraries provide better support
+ (Python Imaging Library [#pil]_).
- + panel
++ panel
- - Undocumented.
+ - Undocumented.
- + panelparser
++ panelparser
- - Undocumented.
+ - Undocumented.
- + readcd
++ readcd
- - Undocumented.
+ - Undocumented.
- + SV
++ SV
- - Undocumented.
+ - Undocumented.
- + torgb
++ torgb
- - Undocumented.
+ - Undocumented.
- + WAIT
++ WAIT
- - Undocumented.
+ - Undocumented.
Mac-specific modules
-////////////////////////////
+////////////////////
The Mac-specific modules are not well-maintained (e.g., the bgen
tool used to auto-generate many of the modules has never been
@@ -261,108 +262,107 @@
* _builtinSuites
- - Undocumented.
- - Package under lib-scriptpackages.
+ - Undocumented.
+ - Package under lib-scriptpackages.
* Audio_mac
- - Undocumented.
+ - Undocumented.
* aepack
- - OSA support is better through third-party modules.
+ - OSA support is better through third-party modules.
- * Appscript [#appscript]_.
+ * Appscript [#appscript]_.
- - Hard-coded endianness which breaks on Intel Macs.
- - Might need to rename if Carbon package dependent.
+ - Hard-coded endianness which breaks on Intel Macs.
+ - Might need to rename if Carbon package dependent.
* aetools
- - See aepack.
+ - See aepack.
* aetypes
- - See aepack.
+ - See aepack.
* applesingle
- - Undocumented.
- - AppleSingle is a binary file format for A/UX.
- - A/UX no longer distributed.
+ - Undocumented.
+ - AppleSingle is a binary file format for A/UX.
+ - A/UX no longer distributed.
* appletrawmain
- - Undocumented.
+ - Undocumented.
* appletrunner
- - Undocumented.
+ - Undocumented.
* argvemulator
- - Undocumented.
+ - Undocumented.
* autoGIL
- - Very bad model for using Python with the CFRunLoop.
+ - Very bad model for using Python with the CFRunLoop.
* bgenlocations
- - Undocumented.
+ - Undocumented.
* buildtools
- - Documented as deprecated since Python 2.3 without an explicit
- reason.
+ - Documented as deprecated since Python 2.3 without an explicit
+ reason.
* bundlebuilder
- - Undocumented.
+ - Undocumented.
* Carbon
- - Carbon development has stopped.
- - Does not support 64-bit systems completely.
- - Dependent on bgen which has never been updated to support UCS-4
- Unicode builds of Python.
+ - Carbon development has stopped.
+ - Does not support 64-bit systems completely.
+ - Dependent on bgen which has never been updated to support UCS-4
+ Unicode builds of Python.
* CodeWarrior
- - Undocumented.
- - Package under lib-scriptpackages.
+ - Undocumented.
+ - Package under lib-scriptpackages.
* ColorPicker
- - Better to use Cocoa for GUIs.
+ - Better to use Cocoa for GUIs.
* EasyDialogs
- - Better to use Cocoa for GUIs.
+ - Better to use Cocoa for GUIs.
* Explorer
- - Undocumented.
- - Package under lib-scriptpackages.
+ - Undocumented.
+ - Package under lib-scriptpackages.
* Finder
- - Undocumented.
- - Package under lib-scriptpackages.
-
+ - Undocumented.
+ - Package under lib-scriptpackages.
* findertools
- - No longer useful.
+ - No longer useful.
* FrameWork
- - Poorly documented.
- - Not updated to support Carbon Events.
+ - Poorly documented.
+ - Not updated to support Carbon Events.
* gensuitemodule
- - See aepack.
+ - See aepack.
* ic
@@ -370,85 +370,84 @@
* icopen
- - Not needed on OS X.
- - Meant to replace 'open' which is usually a bad thing to do.
+ - Not needed on OS X.
+ - Meant to replace 'open' which is usually a bad thing to do.
* macerrors
- - Undocumented.
+ - Undocumented.
* MacOS
- - Would also mean the removal of binhex.
+ - Would also mean the removal of binhex.
* macostools
* macresource
- - Undocumented.
+ - Undocumented.
* MiniAEFrame
- - See aepack.
+ - See aepack.
* Nav
- - Undocumented.
+ - Undocumented.
* Netscape
- - Undocumented.
- - Package under lib-scriptpackages.
+ - Undocumented.
+ - Package under lib-scriptpackages.
* OSATerminology
* pimp
- - Undocumented.
+ - Undocumented.
* PixMapWrapper
- - Undocumented.
+ - Undocumented.
* StdSuites
- - Undocumented.
- - Package under lib-scriptpackages.
+ - Undocumented.
+ - Package under lib-scriptpackages.
* SystemEvents
- - Undocumented.
- - Package under lib-scriptpackages.
+ - Undocumented.
+ - Package under lib-scriptpackages.
* Terminal
- - Undocumented.
- - Package under lib-scriptpackages.
-
+ - Undocumented.
+ - Package under lib-scriptpackages.
* terminalcommand
- - Undocumented.
+ - Undocumented.
* videoreader
- - No longer used.
+ - No longer used.
* W
- - No longer distributed with Python.
+ - No longer distributed with Python.
.. _PyObjC: http://pyobjc.sourceforge.net/
Solaris
-///////////////
+///////
- + SUNAUDIODEV/sunaudiodev
++ SUNAUDIODEV/sunaudiodev
- - Access to the sound card on Sun machines.
- - Code not uniquely edited in over eight years.
+ - Access to the sound card on Sun machines.
+ - Code not uniquely edited in over eight years.
Hardly used [done]
@@ -476,7 +475,6 @@
+ Only useful with the 'sched' module.
+ Not thread-safe.
-
* stringold
+ Function versions of the methods on string objects.
@@ -769,7 +767,7 @@
dbm package
-//////////////////
+///////////
================= ===============================
Current Name Replacement Name
@@ -790,7 +788,7 @@
html package
-///////////////////
+////////////
================== ===============================
Current Name Replacement Name
@@ -801,7 +799,7 @@
http package
-///////////////////
+////////////
================= ===============================
Current Name Replacement Name
@@ -819,7 +817,7 @@
tkinter package
-//////////////////////
+///////////////
================== ===============================
Current Name Replacement Name
@@ -850,7 +848,7 @@
urllib package
-//////////////////////////////////////////////////
+//////////////
Originally this new package was to be named ``url``, but because of
the common use of the name as a variable, it has been deemed better
@@ -873,7 +871,7 @@
xmlrpc package
-/////////////////////
+//////////////
================== ===============================
Current Name Replacement Name
@@ -895,10 +893,8 @@
Issues related to this PEP:
-* `Issue 2775`_
- Master tracking issue
-* `Issue 2828`_
- clean up undoc.rst
+* `Issue 2775`_: Master tracking issue
+* `Issue 2828`_: clean up undoc.rst
.. _Issue 2775: http://bugs.python.org/issue2775
.. _Issue 2828: http://bugs.python.org/issue2828
diff --git a/pep-3121.txt b/pep-3121.txt
--- a/pep-3121.txt
+++ b/pep-3121.txt
@@ -190,13 +190,13 @@
at one point, and lists the following additional hooks which aren't
currently supported in this PEP:
- * when the module object is deleted from sys.modules
+* when the module object is deleted from sys.modules
- * when Py_Finalize is called
+* when Py_Finalize is called
- * when Python exits
+* when Python exits
- * when the Python DLL is unloaded (Windows only)
+* when the Python DLL is unloaded (Windows only)
References
diff --git a/pep-3127.txt b/pep-3127.txt
--- a/pep-3127.txt
+++ b/pep-3127.txt
@@ -24,14 +24,14 @@
The proposal is that:
- a) octal literals must now be specified
- with a leading "0o" or "0O" instead of "0";
+a) octal literals must now be specified
+ with a leading "0o" or "0O" instead of "0";
- b) binary literals are now supported via a
- leading "0b" or "0B"; and
+b) binary literals are now supported via a
+ leading "0b" or "0B"; and
- c) provision will be made for binary numbers in
- string formatting.
+c) provision will be made for binary numbers in
+ string formatting.
Motivation
@@ -39,15 +39,15 @@
This PEP was motivated by two different issues:
- - The default octal representation of integers is silently confusing
- to people unfamiliar with C-like languages. It is extremely easy
- to inadvertently create an integer object with the wrong value,
- because '013' means 'decimal 11', not 'decimal 13', to the Python
- language itself, which is not the meaning that most humans would
- assign to this literal.
+- The default octal representation of integers is silently confusing
+ to people unfamiliar with C-like languages. It is extremely easy
+ to inadvertently create an integer object with the wrong value,
+ because '013' means 'decimal 11', not 'decimal 13', to the Python
+ language itself, which is not the meaning that most humans would
+ assign to this literal.
- - Some Python users have a strong desire for binary support in
- the language.
+- Some Python users have a strong desire for binary support in
+ the language.
Specification
@@ -175,22 +175,22 @@
Throughout this document, unless otherwise noted, discussions about
the string representation of integers relate to these features:
- - Literal integer tokens, as used by normal module compilation,
- by eval(), and by int(token, 0). (int(token) and int(token, 2-36)
- are not modified by this proposal.)
+- Literal integer tokens, as used by normal module compilation,
+ 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.
+- Formatting of integers into strings, either via the % string
+ operator or the new PEP 3101 advanced string formatting method.
It is presumed that:
- - All of these features should have an identical set
- of supported radices, for consistency.
+- All of these features should have an identical set
+ of supported radices, for consistency.
- - Python source code syntax and int(mystring, 0) should
- continue to share identical behavior.
+- Python source code syntax and int(mystring, 0) should
+ continue to share identical behavior.
Removal of old octal syntax
@@ -239,14 +239,14 @@
occasionally or as a matter of habit, use leading zeros for decimal
numbers. Python could either:
- a) silently do the wrong thing with his numbers, as it does now;
+a) silently do the wrong thing with his numbers, as it does now;
- b) immediately disabuse him of the notion that this is viable syntax
- (and yes, the SyntaxWarning should be more gentle than it
- currently is, but that is a subject for a different PEP); or
+b) immediately disabuse him of the notion that this is viable syntax
+ (and yes, the SyntaxWarning should be more gentle than it
+ currently is, but that is a subject for a different PEP); or
- c) let him continue to think that computers are happy with
- multi-digit decimal integers which start with "0".
+c) let him continue to think that computers are happy with
+ multi-digit decimal integers which start with "0".
Some people passionately believe that (c) is the correct answer,
and they would be absolutely right if we could be sure that new
@@ -416,16 +416,16 @@
(sometimes conflicting) requirements and "nice-to-haves" for
this syntax:
- - It should be as compatible with other languages and
- previous versions of Python as is reasonable, both
- for the input syntax and for the output (e.g. string
- % operator) syntax.
+- It should be as compatible with other languages and
+ previous versions of Python as is reasonable, both
+ for the input syntax and for the output (e.g. string
+ % operator) syntax.
- - It should be as obvious to the casual observer as
- possible.
+- It should be as obvious to the casual observer as
+ possible.
- - It should be easy to visually distinguish integers
- formatted in the different bases.
+- It should be easy to visually distinguish integers
+ formatted in the different bases.
Proposed syntaxes included things like arbitrary radix prefixes,
diff --git a/pep-3131.txt b/pep-3131.txt
--- a/pep-3131.txt
+++ b/pep-3131.txt
@@ -144,9 +144,9 @@
It's not clear how that can precisely apply to this PEP; possible
consequences are
- * warn about characters listed as "restricted" in xidmodifications.txt
- * warn about identifiers using mixed scripts
- * somehow perform Confusable Detection
+* warn about characters listed as "restricted" in xidmodifications.txt
+* warn about identifiers using mixed scripts
+* somehow perform Confusable Detection
In the latter two approaches, it's not clear how precisely the
algorithm should work. For mixed scripts, certain kinds of mixing
diff --git a/pep-3137.txt b/pep-3137.txt
--- a/pep-3137.txt
+++ b/pep-3137.txt
@@ -58,11 +58,11 @@
I propose the following type names at the Python level:
- - ``bytes`` is an immutable array of bytes (PyString)
+- ``bytes`` is an immutable array of bytes (PyString)
- - ``bytearray`` is a mutable array of bytes (PyBytes)
+- ``bytearray`` is a mutable array of bytes (PyBytes)
- - ``memoryview`` is a bytes view on another object (PyMemory)
+- ``memoryview`` is a bytes view on another object (PyMemory)
The old type named ``buffer`` is so similar to the new type
``memoryview``, introduce by PEP 3118, that it is redundant. The rest
@@ -116,27 +116,27 @@
There are four forms of constructors, applicable to both bytes and
bytearray:
- - ``bytes(<bytes>)``, ``bytes(<bytearray>)``, ``bytearray(<bytes>)``,
- ``bytearray(<bytearray>)``: simple copying constructors, with the
- note that ``bytes(<bytes>)`` might return its (immutable)
- argument, but ``bytearray(<bytearray>)`` always makes a copy.
+- ``bytes(<bytes>)``, ``bytes(<bytearray>)``, ``bytearray(<bytes>)``,
+ ``bytearray(<bytearray>)``: simple copying constructors, with the
+ note that ``bytes(<bytes>)`` might return its (immutable)
+ argument, but ``bytearray(<bytearray>)`` always makes a copy.
- - ``bytes(<str>, <encoding>[, <errors>])``, ``bytearray(<str>,
- <encoding>[, <errors>])``: encode a text string. Note that the
- ``str.encode()`` method returns an *immutable* bytes object. The
- <encoding> argument is mandatory; <errors> is optional.
- <encoding> and <errrors>, if given, must be ``str`` instances.
+- ``bytes(<str>, <encoding>[, <errors>])``, ``bytearray(<str>,
+ <encoding>[, <errors>])``: encode a text string. Note that the
+ ``str.encode()`` method returns an *immutable* bytes object. The
+ <encoding> argument is mandatory; <errors> is optional.
+ <encoding> and <errrors>, if given, must be ``str`` instances.
- - ``bytes(<memory view>)``, ``bytearray(<memory view>)``: construct
- a bytes or bytearray object from anything that implements the PEP
- 3118 buffer API.
+- ``bytes(<memory view>)``, ``bytearray(<memory view>)``: construct
+ a bytes or bytearray object from anything that implements the PEP
+ 3118 buffer API.
- - ``bytes(<iterable of ints>)``, ``bytearray(<iterable of ints>)``:
- construct a bytes or bytearray object from a stream of integers in
- range(256).
+- ``bytes(<iterable of ints>)``, ``bytearray(<iterable of ints>)``:
+ construct a bytes or bytearray object from a stream of integers in
+ range(256).
- - ``bytes(<int>)``, ``bytearray(<int>)``: construct a
- zero-initialized bytes or bytearray object of a given length.
+- ``bytes(<int>)``, ``bytearray(<int>)``: construct a
+ zero-initialized bytes or bytearray object of a given length.
Comparisons
-----------
@@ -190,26 +190,26 @@
The following operators are implemented by the bytes and bytearray
types, except where mentioned:
- - ``b1 + b2``: concatenation. With mixed bytes/bytearray operands,
- the return type is that of the first argument (this seems arbitrary
- until you consider how ``+=`` works).
+- ``b1 + b2``: concatenation. With mixed bytes/bytearray operands,
+ the return type is that of the first argument (this seems arbitrary
+ until you consider how ``+=`` works).
- - ``b1 += b2``: mutates b1 if it is a bytearray object.
+- ``b1 += b2``: mutates b1 if it is a bytearray object.
- - ``b * n``, ``n * b``: repetition; n must be an integer.
+- ``b * n``, ``n * b``: repetition; n must be an integer.
- - ``b *= n``: mutates b if it is a bytearray object.
+- ``b *= n``: mutates b if it is a bytearray object.
- - ``b1 in b2``, ``b1 not in b2``: substring test; b1 can be any
- object implementing the PEP 3118 buffer API.
+- ``b1 in b2``, ``b1 not in b2``: substring test; b1 can be any
+ object implementing the PEP 3118 buffer API.
- - ``i in b``, ``i not in b``: single-byte membership test; i must
- be an integer (if it is a length-1 bytes array, it is considered
- to be a substring test, with the same outcome).
+- ``i in b``, ``i not in b``: single-byte membership test; i must
+ be an integer (if it is a length-1 bytes array, it is considered
+ to be a substring test, with the same outcome).
- - ``len(b)``: the number of bytes.
+- ``len(b)``: the number of bytes.
- - ``hash(b)``: the hash value; only implemented by the bytes type.
+- ``hash(b)``: the hash value; only implemented by the bytes type.
Note that the % operator is *not* implemented. It does not appear
worth the complexity.
diff --git a/pep-3147.txt b/pep-3147.txt
--- a/pep-3147.txt
+++ b/pep-3147.txt
@@ -426,8 +426,8 @@
To support this use case, we'll add two new methods to the `imp`
package [17]_:
- * `imp.cache_from_source(py_path)` -> `pyc_path`
- * `imp.source_from_cache(pyc_path)` -> `py_path`
+* `imp.cache_from_source(py_path)` -> `pyc_path`
+* `imp.source_from_cache(pyc_path)` -> `py_path`
Alternative implementations are free to override these functions to
return reasonable values based on their own support for this PEP.
diff --git a/pep-3149.txt b/pep-3149.txt
--- a/pep-3149.txt
+++ b/pep-3149.txt
@@ -117,9 +117,9 @@
tag as appropriate. For example, on POSIX systems these flags will
also contribute to the file name:
- * ``--with-pydebug`` (flag: ``d``)
- * ``--with-pymalloc`` (flag: ``m``)
- * ``--with-wide-unicode`` (flag: ``u``)
+* ``--with-pydebug`` (flag: ``d``)
+* ``--with-pymalloc`` (flag: ``m``)
+* ``--with-wide-unicode`` (flag: ``u``)
By default in Python 3.2, ``configure`` enables ``--with-pymalloc`` so
shared library file names would appear as ``foo.cpython-32m.so``.
@@ -224,13 +224,13 @@
Martin v. Löwis describes his thoughts [7]_ about the applicability of this
PEP to PEP 384. In summary:
- * ``--with-pydebug`` would not be supported by the stable ABI because
- this changes the layout of ``PyObject``, which is an exposed
- structure.
- * ``--with-pymalloc`` has no bearing on the issue.
- * ``--with-wide-unicode`` is trickier, though Martin's inclination is
- to force the stable ABI to use a ``Py_UNICODE`` that matches the
- platform's ``wchar_t``.
+* ``--with-pydebug`` would not be supported by the stable ABI because
+ this changes the layout of ``PyObject``, which is an exposed
+ structure.
+* ``--with-pymalloc`` has no bearing on the issue.
+* ``--with-wide-unicode`` is trickier, though Martin's inclination is
+ to force the stable ABI to use a ``Py_UNICODE`` that matches the
+ platform's ``wchar_t``.
Alternatives
diff --git a/pep-3150.txt b/pep-3150.txt
--- a/pep-3150.txt
+++ b/pep-3150.txt
@@ -60,15 +60,15 @@
current list of simple statements that would be affected by this
addition is as follows:
- * expression statement
- * assignment statement
- * augmented assignment statement
- * del statement
- * return statement
- * yield statement
- * raise statement
- * assert statement
- * pass statement
+* expression statement
+* assignment statement
+* augmented assignment statement
+* del statement
+* return statement
+* yield statement
+* raise statement
+* assert statement
+* pass statement
The ``given`` clause would allow subexpressions to be referenced by
name in the header line, with the actual definitions following in
@@ -238,17 +238,17 @@
PEP proposes the following additions for ``given`` statements to the
"Programming Conventions" section of PEP 8:
- - for code that could reasonably be factored out into a separate function,
- but is not currently reused anywhere, consider using a ``given`` clause.
- This clearly indicates which variables are being used only to define
- subcomponents of another statement rather than to hold algorithm or
- application state. This is an especially useful technique when
- passing multi-line functions to operations which take callable
- arguments.
+- for code that could reasonably be factored out into a separate function,
+ but is not currently reused anywhere, consider using a ``given`` clause.
+ This clearly indicates which variables are being used only to define
+ subcomponents of another statement rather than to hold algorithm or
+ application state. This is an especially useful technique when
+ passing multi-line functions to operations which take callable
+ arguments.
- - keep ``given`` clauses concise. If they become unwieldy, either break
- them up into multiple steps or else move the details into a separate
- function.
+- keep ``given`` clauses concise. If they become unwieldy, either break
+ them up into multiple steps or else move the details into a separate
+ function.
Rationale
--
Repository URL: https://hg.python.org/peps
More information about the Python-checkins
mailing list