You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Use .rst as the file extension for reST-based PEPs #1
Requires not only renaming all relevant files but also updating code to accept the file extension. As part of this we can probably consider dropping the Content-Type as it will be known from the file extension (although others may disagree).
This will allow for rich rendering of the reST-based PEPS by GitHub.
Looks like www.python.org/dev/peps/ will now display PEPs with a .rst ending as demonstrated by PEP 550! The next problem is that the source link at the end of PEPs don't work for PEPs that end in .rst.
The problem is the converter doesn't know anything about the source file so we probably need to guess the extension (maybe do a HEAD request to .txt first; if status is not 200; try .rst?)
What I'm expecting is once #4 is done we can update the converter to assume .rst and then start moving all the file names over so it won't matter what the assumption is.
I learned in #462 that renaming a file on GitHub has a side effect of not being able to view the file's complete history. For example, after pep-0008.txt was renamed to pep-0008.rst, GitHub is only showing the history of pep-0008.rst as if it is a new file.
Using the command line, git log pep-0008.rst only shows the revision history after the rename.
To get the full history of PEP 8 since the very beginning, we need to do git log --follow pep-0008.rst.
To me, not being able to view the full revision history on GitHub is a major inconvenience. I reverted that PR so everything is back to *.txt again.
I use the online history browser to check "When did such & such a change happen?", so losing annotations would be more annoying than not having inline rendering.
So using .rst for new PEPs, and leaving existing ones alone sounds like a reasonable compromise to me (unless/until GitHub update their history browser and annotation display to handle renames)
So using .rst for new PEPs, and leaving existing ones alone sounds like a reasonable compromise to me (unless/until GitHub update their history browser and annotation display to handle renames)
Do realize that leaving old PEPs as-is will still require a code change as the link back to the PEP source will still be broken (right now it blindly assumes it's a .txt file).
Activity
ncoghlan commentedon Jun 25, 2016
#32 covers supporting .rst as an extension in the Makefile and PEP 0 generator
Merge pull request #1 from ilevkivskyi/master
ncoghlan commentedon Oct 14, 2016
@berkerpeksag mentioned in #116 that the
.rstextension isn't supported by the python.org importer yet.I think that may be the only remaining barrier to a bulk rename of the existing text/x-rst PEPs.
brettcannon commentedon Oct 14, 2016
That's been my assumption as well about where things stand.
brettcannon commentedon Dec 10, 2016
This issue is also dependent on #4 .
brettcannon commentedon Aug 16, 2017
Looks like www.python.org/dev/peps/ will now display PEPs with a
.rstending as demonstrated by PEP 550! The next problem is that the source link at the end of PEPs don't work for PEPs that end in.rst.berkerpeksag commentedon Aug 17, 2017
The problem is the converter doesn't know anything about the source file so we probably need to guess the extension (maybe do a HEAD request to
.txtfirst; if status is not 200; try.rst?)brettcannon commentedon Aug 17, 2017
What I'm expecting is once #4 is done we can update the converter to assume
.rstand then start moving all the file names over so it won't matter what the assumption is.gvanrossum commentedon Sep 12, 2017
Hm... The source link thing is sad. Where's the code for the converter?
ncoghlan commentedon Sep 13, 2017
This is the offending line in the web app: https://github.com/python/pythondotorg/blob/master/peps/converters.py#L184
I'm thinking it may make sense to move that part out of the web app and into
pep2html.py.gvanrossum commentedon Sep 13, 2017
Rename all .txt PEP files to .rst (GH-462)
Mariatta commentedon Nov 12, 2017
I learned in #462 that renaming a file on GitHub has a side effect of not being able to view the file's complete history. For example, after
pep-0008.txtwas renamed topep-0008.rst, GitHub is only showing the history ofpep-0008.rstas if it is a new file.(The "History" I'm referring to is the button on GitHub when you're viewing the file: https://github.com/python/peps/blob/master/pep-0008.txt:)

Using the command line,
git log pep-0008.rstonly shows the revision history after the rename.To get the full history of PEP 8 since the very beginning, we need to do
git log --follow pep-0008.rst.To me, not being able to view the full revision history on GitHub is a major inconvenience. I reverted that PR so everything is back to
*.txtagain.gvanrossum commentedon Nov 12, 2017
Rosuav commentedon Nov 12, 2017
Personally, I just use the command-line git tools, or
gitk. If GitHub can't track across renames, that's their problem, not ours.ncoghlan commentedon Nov 12, 2017
I use the online history browser to check "When did such & such a change happen?", so losing annotations would be more annoying than not having inline rendering.
So using
.rstfor new PEPs, and leaving existing ones alone sounds like a reasonable compromise to me (unless/until GitHub update their history browser and annotation display to handle renames)berkerpeksag commentedon Nov 13, 2017
+1.
brettcannon commentedon Nov 14, 2017
Do realize that leaving old PEPs as-is will still require a code change as the link back to the PEP source will still be broken (right now it blindly assumes it's a
.txtfile).ncoghlan commentedon Nov 15, 2017
Right, we should still pull that snippet out of the website code and move it into pep2html.py
Mariatta commentedon Nov 16, 2017
The link back to the PEP source has been fixed in python/pythondotorg#1195.
brettcannon commentedon Nov 16, 2017
So is this considered done at this point then?
ncoghlan commentedon Nov 17, 2017
Aye, looks done to me - if we find anything else missing, it can become a new issue.
ncoghlan commentedon Nov 17, 2017
Thanks to all involved in getting this done!
pradyunsg commentedon May 22, 2018
Relevant here: isaacs/github#900
Merge pull request python#1 from mnm678:bins_offline
Syntax highlighting (python#1)