PEPs shouldn't be considered docs
I wanted to teach a co-worker about "from __future__ import absolute_import" today, so I thought I'd point them at the docs. The page for "__future__" starts with a bunch of internal details that almost no one needs to know. There's a table at the end that mentions the actual importable names, including "absolute_import", but says nothing about then except to link to a PEP. The absolute imports PEP has no simple description of what it does. Like many PEPs, it's mostly a summary of the debate around the design of the feature. The closest the PEP comes to describing the behavior of "absolute_import" is this parenthetical: For the second problem, it is proposed that all import statements be absolute by default (searching sys.path only) with special syntax (leading dots) for accessing package-relative imports. And notice: that sentence describes it as a "proposal." I'd like to suggest that we not consider PEPs to be documentation. If a PEP has a good succinct description of how something works, then let's copy that text into the documentation at an appropriate place. If a PEP doesn't have such a description, then all the more reason not to send readers there. A link to the PEP is appropriate as a "see also" in the docs, but we shouldn't pretend that a PEP addresses the needs of people new to the feature. --Ned.
2013/10/11 Ned Batchelder
I wanted to teach a co-worker about "from __future__ import absolute_import" today, so I thought I'd point them at the docs. The page for "__future__" starts with a bunch of internal details that almost no one needs to know. There's a table at the end that mentions the actual importable names, including "absolute_import", but says nothing about then except to link to a PEP.
The absolute imports PEP has no simple description of what it does. Like many PEPs, it's mostly a summary of the debate around the design of the feature. The closest the PEP comes to describing the behavior of "absolute_import" is this parenthetical:
For the second problem, it is proposed that all import statements be absolute by default (searching sys.path only) with special syntax (leading dots) for accessing package-relative imports.
And notice: that sentence describes it as a "proposal."
I'd like to suggest that we not consider PEPs to be documentation. If a PEP has a good succinct description of how something works, then let's copy that text into the documentation at an appropriate place. If a PEP doesn't have such a description, then all the more reason not to send readers there.
+1 The writing required to specificy and adovocate a feature are usually quite different from that needed to document it. PEPs also get out of date rather quickly. -- Regards, Benjamin
On 11 Oct 2013 21:25, "Ned Batchelder"
I wanted to teach a co-worker about "from __future__ import
absolute_import" today, so I thought I'd point them at the docs. The page for "__future__" starts with a bunch of internal details that almost no one needs to know. There's a table at the end that mentions the actual importable names, including "absolute_import", but says nothing about then except to link to a PEP.
The absolute imports PEP has no simple description of what it does. Like
For the second problem, it is proposed that all import statements be
absolute by default (searching sys.path only) with special syntax (leading dots) for accessing package-relative imports.
And notice: that sentence describes it as a "proposal."
I'd like to suggest that we not consider PEPs to be documentation. If a PEP has a good succinct description of how something works, then let's copy
many PEPs, it's mostly a summary of the debate around the design of the feature. The closest the PEP comes to describing the behavior of "absolute_import" is this parenthetical: that text into the documentation at an appropriate place. If a PEP doesn't have such a description, then all the more reason not to send readers there.
A link to the PEP is appropriate as a "see also" in the docs, but we
shouldn't pretend that a PEP addresses the needs of people new to the feature. Aside from PEPs that describe development practices and versioned interoperability standards, this is already the case. The only major deviation from this practice was the import system, and that was because it was such an incoherent organically grown mess in CPython prior to the importlib migration in Python 3.3 that nobody was prepared to take on the task of writing the reference docs. Providing the missing reference docs for the import system was one of the conditions placed on the introduction of namespace packages in PEP 420. There's no grand policy change or clarification needed here, it's just another consequence of the fact that the import system isn't documented properly in versions prior to 3.3. Cheers, Nick.
--Ned.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
On 12 October 2013 00:29, Nick Coghlan
There's no grand policy change or clarification needed here, it's just another consequence of the fact that the import system isn't documented properly in versions prior to 3.3.
And my personal apology for that. I knew when we wrote PEP 302 that it needed proper documentation, but I couldn't find a good way to include it in the docs and I couldn't face rewriting the import docs in a way that would allow me to include it. Many thanks to Brett for ultimately doing it for me. Paul
On Sat, Oct 12, 2013 at 5:38 AM, Paul Moore
On 12 October 2013 00:29, Nick Coghlan
wrote: There's no grand policy change or clarification needed here, it's just another consequence of the fact that the import system isn't documented properly in versions prior to 3.3.
And my personal apology for that. I knew when we wrote PEP 302 that it needed proper documentation, but I couldn't find a good way to include it in the docs and I couldn't face rewriting the import docs in a way that would allow me to include it.
Many thanks to Brett for ultimately doing it for me.
Actually thanks should go to Barry who rewrote the language ref docs for import.
On 12 Oct 2013 19:38, "Paul Moore"
On 12 October 2013 00:29, Nick Coghlan
wrote: There's no grand policy change or clarification needed here, it's just another consequence of the fact that the import system isn't documented properly in versions prior to 3.3.
And my personal apology for that. I knew when we wrote PEP 302 that it needed proper documentation, but I couldn't find a good way to include it in the docs and I couldn't face rewriting the import docs in a way that would allow me to include it.
You were *far* from the only one to contemplate documenting the old import system and then decide we had more edifying things to do with our time ;)
Many thanks to Brett for ultimately doing it for me.
Barry actually did the bulk of the initial writing for that, although Brett did the preceding work to make it feasible to document by ensuring the default import system was registered on sys.meta_path. And yes, it was a very happy day when that commit landed :) Cheers, Nick.
Paul
participants (7)
-
Barry Warsaw
-
Benjamin Peterson
-
Brett Cannon
-
Ethan Furman
-
Ned Batchelder
-
Nick Coghlan
-
Paul Moore