diff --git a/pep-0413.txt b/pep-0413.txt index b60bbfbbf..8ac26f6b7 100644 --- a/pep-0413.txt +++ b/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