Formatting fixes, wording update on the comment about tagging as a way of communicating
This commit is contained in:
Nick Coghlan
parent
828ed616fd
commit
ed270777a0
71
pep-0413.txt
71
pep-0413.txt
|
|
@ -184,14 +184,14 @@ special.
|
|||
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 @@ version numbers. I call this a tie.
|
|||
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 @@ compatibility is important).
|
|||
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 @@ separate number avoids creating unnecessary confusion.
|
|||
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 @@ they happen (especially pure Python changes), leaving minor version number
|
|||
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 @@ slim margin).
|
|||
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
|
||||
|
|
|
|||
Loading…
Reference in New Issue