[Python-checkins] peps: Formatting fixes, wording update on the comment about tagging as a way of

Sat Feb 25 09:42:55 CET 2012

http://hg.python.org/peps/rev/cc186e9b167f
changeset: 4075:cc186e9b167f
user: Nick Coghlan <ncoghlan at gmail.com>
date: Sat Feb 25 18:42:49 2012 +1000
summary:
 Formatting fixes, wording update on the comment about tagging as a way of communicating
files:
 pep-0413.txt | 71 ++++++++++++++++++++-------------------
 1 files changed, 36 insertions(+), 35 deletions(-)

diff --git a/pep-0413.txt b/pep-0413.txt
--- a/pep-0413.txt
+++ b/pep-0413.txt
@@ -184,14 +184,14 @@
 Novice user, downloading Python from python.org in March 2013
 -------------------------------------------------------------
 
-*Status quo:* must choose between 3.3 and 2.7
+**Status quo:** must choose between 3.3 and 2.7
 
-*This PEP:* must first choose between 3.3 and 2.7. If choosing 3.3, must then
+**This PEP:** must first choose between 3.3 and 2.7. If choosing 3.3, must then
 choose between 3.3 (13.02) or 3.3 (12.08)
 
-*PEP 407:* must choose between 3.4, 3.3 (LTS) and 2.7.
+**PEP 407:** must choose between 3.4, 3.3 (LTS) and 2.7.
 
-Verdict: explaining the meaning of a Long Term Support release is about as
+**Verdict:** explaining the meaning of a Long Term Support release is about as
 complicated as explaining the meaning of the proposed standard library
 version numbers. I call this a tie.
 
@@ -199,19 +199,19 @@
 Novice user, looking for appropriate binary release
 ---------------------------------------------------
 
-*Status quo:* look for the binary corresponding to the Python version you are
+**Status quo:** look for the binary corresponding to the Python version you are
 running.
 
-*This PEP:* same as status quo.
+**This PEP:** same as status quo.
 
-*PEP 407 (full releases):* same as status quo, but corresponding binary version
+**PEP 407 (full releases):** same as status quo, but corresponding binary version
 is more likely to be missing (or, if it does exist, has to be found amongst
 a much larger list of alternatives).
 
-*PEP 407 (ABI updates limited to LTS releases):* all binary release pages will
+**PEP 407 (ABI updates limited to LTS releases):** all binary release pages will
 need to tell users that Python 3.3, 3.4 and 3.5 all need the 3.3 binary.
 
-Verdict: I call this a clear win for the scheme in this PEP. Absolutely
+**Verdict:** I call this a clear win for the scheme in this PEP. Absolutely
 nothing changes from the current situation, since the standard library
 version is actually irrelevant in this case (only binary extension
 compatibility is important).
@@ -220,19 +220,19 @@
 Extension module author, deciding whether or not to make a binary release
 -------------------------------------------------------------------------
 
-*Status quo:* unless using the PEP 384 stable ABI, a new binary release is
+**Status quo:** unless using the PEP 384 stable ABI, a new binary release is
 needed every time the minor version number changes.
 
-*This PEP:* same as status quo.
+**This PEP:** same as status quo.
 
-*PEP 407 (full releases):* same as status quo, but becomes a far more
+**PEP 407 (full releases):** same as status quo, but becomes a far more
 frequent occurrence.
 
-*PEP 407 (ABI updates limited to LTS releases):* before deciding, must first
+**PEP 407 (ABI updates limited to LTS releases):** before deciding, must first
 look up whether the new release is an LTS release or an interim release. If
 it is an LTS release, then a new build is necessary.
 
-Verdict: I call this another clear win for the scheme in this PEP. As with
+**Verdict:** I call this another clear win for the scheme in this PEP. As with
 the end user facing side of this problem, the standard library version is
 actually irrelevant in this case. Moving that information out to a
 separate number avoids creating unnecessary confusion.
@@ -241,28 +241,28 @@
 Python developer, deciding priority of eliminating a Deprecation Warning
 ------------------------------------------------------------------------
 
-*Status quo:* code that triggers deprecation warnings is not guaranteed to
+**Status quo:** code that triggers deprecation warnings is not guaranteed to
 run on a version of Python with a higher minor version number.
 
-*This PEP:* same as status quo
+**This PEP:** same as status quo
 
-*PEP 407:* unclear, as the PEP doesn't currently spell this out. Assuming the
+**PEP 407:** unclear, as the PEP doesn't currently spell this out. Assuming the
 deprecation cycle is linked to LTS releases, then upgrading to a non-LTS
 release is safe but upgrading to the next LTS release may require avoiding
 the deprecated construct.
 
-Verdict: another clear win for the scheme in this PEP since, once again, the
+**Verdict:** another clear win for the scheme in this PEP since, once again, the
 standard library version is irrelevant in this scenario.
 
 
 Alternative interpreter implementor, updating with new features
 ---------------------------------------------------------------
 
-*Status quo:* new Python versions arrive infrequently, but are a mish-mash of
+**Status quo:** new Python versions arrive infrequently, but are a mish-mash of
 standard library updates and core language definition and interpreter
 changes.
 
-*This PEP:* standard library updates, which are easier to integrate, are
+**This PEP:** standard library updates, which are easier to integrate, are
 made available more frequently in a form that is clearly and explicitly
 compatible with the previous version of the language definition. This means
 that, once an alternative implementation catches up to Python 3.3, they
@@ -271,38 +271,39 @@
 updates as the only task that requires updates to their core compilation and
 execution components.
 
-*PEP 407 (full releases):* same as status quo, but becomes a far more
+**PEP 407 (full releases):** same as status quo, but becomes a far more
 frequent occurrence.
 
-*PEP 407 (language updates limited to LTS releases):* unclear, as the PEP
+**PEP 407 (language updates limited to LTS releases):** unclear, as the PEP
 doesn't currently spell out a specific development strategy. Assuming a
 3.3 compatibility branch is adopted (as proposed in this PEP), then the
 outcome would be much the same, but the version number signalling would be
 slightly less clear (since you would have to look up to see if a particular
 release was an LTS release or not).
 
-Verdict: while not as clear cut as some previous scenarios, I'm still calling
-this one in favour of the scheme in this PEP. Explicit is better than
+**Verdict:** while not as clear cut as some previous scenarios, I'm still
+calling this one in favour of the scheme in this PEP. Explicit is better than
 implicit, and the scheme in this PEP makes a clear split between the two
 different kinds of update rather than adding a separate "LTS" tag to an
-otherwise ordinary release number. Tagging is great for version control
-systems, but it's a lousy way to communicate information to other humans.
-
+otherwise ordinary release number. Tagging a particular version as being
+special is great for communicating with version control systems and associated
+automated tools, but it's a lousy way to communicate information to other
+humans.
 
 Python developer, deciding their minimum version dependency
 -----------------------------------------------------------
 
-*Status quo:* look for "version added" or "version tagged" markers in the
+**Status quo:** look for "version added" or "version tagged" markers in the
 documentation, check against ``sys.version_info``
 
-*This PEP:* look for "version added" or "version tagged" markers in the
+**This PEP:** look for "version added" or "version tagged" markers in the
 documentation. If written as a bare Python version, such as "3.3", check
 against ``sys.version_info``. If qualified with a standard library version,
 such as "3.3 (13.02)", check against ``sys.stdlib_info``.
 
-*PEP 407:* same as status quo
+**PEP 407:** same as status quo
 
-Verdict: the scheme in this PEP actually allows third party libraries to be
+**Verdict:** the scheme in this PEP actually allows third party libraries to be
 more explicit about their rate of adoption of standard library features. More
 conservative projects will likely pin their dependency to the language
 version and avoid features added in the standard library releases. Faster
@@ -315,18 +316,18 @@
 Python developers, attempting to reproduce a tracker issue
 ----------------------------------------------------------
 
-*Status quo:* if not already provided, ask the reporter which version of
+**Status quo:** if not already provided, ask the reporter which version of
 Python they're using. This is often done by asking for the first two lines
 displayed by the interactive prompt or the value of ``sys.version``.
 
-*This PEP:* same as the status quo (as ``sys.version`` will be updated to
+**This PEP:** same as the status quo (as ``sys.version`` will be updated to
 also include the standard library version), but may be needed on additional
 occasions (where the user knew enough to state their Python version, but that
 proved to be insufficient to reproduce the fault).
 
-*PEP 407:* same as the status quo
+**PEP 407:** same as the status quo
 
-Verdict: another marginal win for PEP 407. The new standard library version
+**Verdict:** another marginal win for PEP 407. The new standard library version
 *is* an extra piece of information that users may need to pass back to
 developers when reporting issues with Python libraries (or Python itself,
 on our own tracker). However, by including it in ``sys.version``, many
-- 
Repository URL: http://hg.python.org/peps
