Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PEP 639: Update header, footer, link, reference and code block syntax #2531

Merged
merged 4 commits into from
Apr 19, 2022

Conversation

CAM-Gerlach
Copy link
Member

This is part 1 in (finally) updating PEP 639 (again). This first part just makes straightforward technical changes to update the headers in line with the current guidance, take advantage of the new syntax allowed by PEP 676's implementation, prepare for moving most of the ancillary/appendix material elsewhere, and fix a handful of technical and textual issues discovered during the process.

Specifically, it uses the recommended :ref: role for internal links, so that links (particularly cross-document ones) still work after renaming things and moving them around (among other benefits), ensures the external links are all uniformly anonymous to avoid conflicts, and strips the # from the target names to avoid confusion with footnotes or with URI fragments, and ensures the proper syntax highlighting is applied to each code block, as currently they are all over the place.

This should be able to be reviewed and merged fairly quickly; the next part will contain the actual meat (principally, changing the project source metadata to use the existing license key and updating the various dependent sections accordingly, plus bumping the metadata version, changing license_files to licenses in .dist-info, and ensuring this PEP reflects that the original intent of PEP 621 license.file was to be read in as text as the value of the License field (which was not at all initially clear from the PEP/spec, despite multiple re-reads). The final part will move the various appendices and the Rejected Ideas to separate linked auxiliary files (retaining a high-level summary of the latter in the PEP).

@CAM-Gerlach CAM-Gerlach requested a review from a team April 16, 2022 03:23
@CAM-Gerlach CAM-Gerlach self-assigned this Apr 16, 2022
Copy link
Member

@JelleZijlstra JelleZijlstra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good

pep-0639.rst Outdated
Discussions-To: https://discuss.python.org/t/12622
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 15-Aug-2019
Post-History: 15-Aug-2019, 17-Dec-2021
Post-History: `15-Aug-2019 <https://discuss.python.org/t/2154>`__,
`17-Dec-2021 <https://discuss.python.org/t/12622>`__,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

Do we need this final comma, or will some other tooling/CSS remove from display it later?

Suggested change
`17-Dec-2021 <https://discuss.python.org/t/12622>`__,
`17-Dec-2021 <https://discuss.python.org/t/12622>`__

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great catch; while the linting checks in #2484 explicitly allow (but of course not require) trailing commas (for the same reasons as in Python source), I'd somehow forgotten that the build system wasn't actually automatically trimming them yet in the output. I've implemented that as part of #2467 , which is blocked on #2484 , which would suggest merging those first...but wait, the plot thickens.

As part of that, looking through the code I actually happened to notice a significant problem with allowing manual email obfuscation, which makes the automatic obfuscation not work and actually offers substantially less protection, which I discuss in #2484 (and affects this PEP, which this PR fixes). As such, that either requires a pretty complex code fix (which would take some thought and effort before its ready), or reverting part of the reversion to allow naive manual email obfuscation in the source (which would in turn require either some of the changes in this PEP, or conflicting with it). So we have a PR reference cycle, heh.

To fix this for now, I fixuped the initial commit to not add the trailing comma, as well as one other minor fix, so this should be ready now.

@CAM-Gerlach
Copy link
Member Author

Going to go ahead with this now, since these are just technical changes and its soft-blocking #2484

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants