221 lines
7.8 KiB
ReStructuredText
221 lines
7.8 KiB
ReStructuredText
PEP: 430
|
|
Title: Migrating to Python 3 as the default online documentation
|
|
Version: $Revision$
|
|
Last-Modified: $Date$
|
|
Author: Alyssa Coghlan <ncoghlan@gmail.com>
|
|
BDFL-Delegate: Georg Brandl
|
|
Status: Final
|
|
Type: Informational
|
|
Content-Type: text/x-rst
|
|
Created: 27-Oct-2012
|
|
|
|
|
|
Abstract
|
|
========
|
|
|
|
This PEP proposes a strategy for migrating the default version of the
|
|
Python documentation presented to users of Python when accessing
|
|
docs.python.org from 2.7 to Python 3.3.
|
|
|
|
It proposes a backwards compatible scheme that preserves the meaning of
|
|
existing deep links in to the Python 2 documentation, while still
|
|
presenting the Python 3 documentation by default, and presenting the
|
|
Python 2 and 3 documentation in a way that avoids making the Python 3
|
|
documentation look like a second-class citizen.
|
|
|
|
|
|
Background
|
|
==========
|
|
|
|
With the transition of the overall Python ecosystem from Python 2 to Python 3
|
|
still in progress, one question which arises periodically [1]_, [2]_ is when
|
|
and how to handle the change from providing the Python 2 documentation as
|
|
the default version displayed at the docs.python.org root URL to providing
|
|
the Python 3 documentation.
|
|
|
|
|
|
Key Concerns
|
|
============
|
|
|
|
There are a couple of key concerns that any migration proposal needs to
|
|
address.
|
|
|
|
|
|
Don't Confuse Beginners
|
|
-----------------------
|
|
|
|
Many beginners learn Python through third party resources. These resources,
|
|
not all of which are online resources, may reference in to the python.org
|
|
online documentation for additional background and details.
|
|
|
|
Importantly, even when the online documentation is updated, the "version
|
|
added" and "version changed" tags usually provide enough information for
|
|
users to adjust appropriately for the specific version they are using.
|
|
|
|
While deep links in to the python.org documentation may occasionally break
|
|
within the Python 2 series, this is very rare.
|
|
|
|
Migrating to Python 3 is a very different matter. Many links would break due
|
|
to renames and removals, and the "version added" and "version changed"
|
|
information for the Python 2 series is completely absent.
|
|
|
|
|
|
Don't Break Useful Resources
|
|
----------------------------
|
|
|
|
There are many useful Python resources out there, such as the mailing list
|
|
archives on python.org and question-and-answer sites like Stack Overflow,
|
|
where links are highly unlikely to be updated, no matter how much notice
|
|
is provided.
|
|
|
|
Old posts and answers to questions all currently link to docs.python.org
|
|
expecting to get the Python 2 documentation at unqualified URLs. Links from
|
|
answers that relate to Python 3 are explicitly qualified with ``/py3k/`` in
|
|
the path component.
|
|
|
|
|
|
Proposal
|
|
========
|
|
|
|
This PEP (based on an idea originally put forward back in May [3]_) is to
|
|
*not migrate* the Python 2 specific deep links at all, and instead adopt a
|
|
scheme where all URLs presented to users on docs.python.org are qualified
|
|
appropriately with the relevant release series.
|
|
|
|
Visitors to the root URL at ``http://docs.python.org`` will be automatically
|
|
redirected to ``http://docs.python.org/3/``, but links deeper in
|
|
the version-specific hierarchy, such as to
|
|
``http://docs.python.org/library/os``, will instead be redirected to
|
|
a Python 2 specific link such as ``http://docs.python.org/2/library/os``.
|
|
|
|
The specific subpaths which will be redirected to explicitly qualified
|
|
paths for the Python 2 docs are:
|
|
|
|
* ``/c-api/``
|
|
* ``/distutils/``
|
|
* ``/extending/``
|
|
* ``/faq/``
|
|
* ``/howto/``
|
|
* ``/library/``
|
|
* ``/reference/``
|
|
* ``/tutorial/``
|
|
* ``/using/``
|
|
* ``/whatsnew/``
|
|
* ``/about.html``
|
|
* ``/bugs.html``
|
|
* ``/contents.html``
|
|
* ``/copyright.html``
|
|
* ``/license.html``
|
|
* ``/genindex.html``
|
|
* ``/glossary.html``
|
|
* ``/py-modindex.html``
|
|
* ``/search.html``
|
|
|
|
The existing ``/py3k/`` subpath will be redirected to the new ``/3/``
|
|
subpath.
|
|
|
|
|
|
Presented URLs
|
|
--------------
|
|
|
|
With this scheme, the following URLs would be presented to users after
|
|
resolution of any aliasing and rewriting rules:
|
|
|
|
* ``http://docs.python.org/x/*``
|
|
* ``http://docs.python.org/x.y/*``
|
|
* ``http://docs.python.org/dev/*``
|
|
* ``http://docs.python.org/release/x.y.z/*``
|
|
* ``http://docs.python.org/devguide``
|
|
|
|
The ``/x/`` URLs mean "give me the latest documentation for a released
|
|
version in this release series". It will draw the documentation from the
|
|
relevant maintenance branch in source control (this will always be the
|
|
2.7 branch for Python 2 and is currently 3.3 for Python 3). Differences
|
|
relative to previous versions in the release series will be available
|
|
through "version added" and "version changed" markers.
|
|
|
|
The ``/x.y/`` URLs mean "give me the latest documentation for this release".
|
|
It will draw the documentation from the relevant maintenance branch in
|
|
source control (or the default branch for the currently in development
|
|
version). It differs from the status quo in that the URLs will
|
|
actually remain available in the user's browser for easy copy and pasting.
|
|
(Currently, references to specific versions that are not the latest in their
|
|
release series will resolve to a stable URL for a specific maintenance
|
|
version in the "release" hierarchy, while the current latest version in the
|
|
release series resolves to the release series URL. This makes it hard to get
|
|
a "latest version specific URL", since it is always necessary to construct
|
|
them manually).
|
|
|
|
The ``/dev/`` URL means the documentation for the default branch in source
|
|
control.
|
|
|
|
The ``/release/x.y.x/`` URLs will refer to the documentation of those
|
|
releases, exactly as it was at the time of the release.
|
|
|
|
The developer's guide is not version specific, and thus retains its own
|
|
stable ``/devguide/`` URL.
|
|
|
|
Rationale
|
|
=========
|
|
|
|
There is some desire to switch the unqualified references to mean Python 3
|
|
as a sign of confidence in Python 3. Such a move would either break a lot of
|
|
things, or else involve an awful lot of work to *avoid* breaking things.
|
|
|
|
I believe we can get much the same effect without breaking the world by:
|
|
|
|
1. Deprecating the use of unqualified references to the online
|
|
documentation (while promising to preserve the meaning of such
|
|
references indefinitely)
|
|
2. Updating all python.org and python-dev controlled links to use
|
|
qualified references (excluding archived email)
|
|
3. Redirecting visitors to the root of ``http://docs.python.org`` to
|
|
``http://docs.python.org/3.x``
|
|
|
|
Most importantly, because this scheme doesn't alter the behaviour of any
|
|
existing deep links, it could be implemented with a significantly shorter
|
|
warning period than would be required for a scheme that risked breaking
|
|
deep links, or started to redirect unqualified links to Python 3. The
|
|
only part of the scheme which would require any warning at all is the
|
|
step of redirecting the "http://docs.python.org/" landing page to the
|
|
Python 3.3 documentation.
|
|
|
|
Namespaces are one honking great idea - let's do more of those.
|
|
|
|
Note that the approach described in this PEP gives two ways to access the
|
|
content of the default branch: as ``/dev/`` or using the appropriate
|
|
``/x.y/`` reference. This is deliberate, as the default branch is referenced
|
|
for two different purposes:
|
|
|
|
* to provide additional information when discussing an upcoming feature of
|
|
the next release (a ``/x.y/`` URL is appropriate)
|
|
* to provide a stable destination for developers to access the documentation
|
|
of the next feature release, regardless of the version (a ``/dev/`` URL is
|
|
appropriate)
|
|
|
|
|
|
Implementation
|
|
==============
|
|
|
|
The URLs on docs.python.org are controlled by the python.org infrastructure
|
|
team rather than through the CPython source repo, so acceptance and
|
|
implementation of the ideas in this PEP will be up to the team.
|
|
|
|
|
|
References
|
|
==========
|
|
|
|
.. [1] May 2012 discussion
|
|
(https://mail.python.org/pipermail/python-dev/2012-May/119524.html)
|
|
|
|
.. [2] October 2012 discussion
|
|
(https://mail.python.org/pipermail/python-ideas/2012-October/017406.html)
|
|
|
|
.. [3] Using a "/latest/" path prefix
|
|
(https://mail.python.org/pipermail/python-dev/2012-May/119567.html)
|
|
|
|
|
|
Copyright
|
|
===========
|
|
This document has been placed in the public domain.
|