PEP 682: Discussions-To and minor fixes

[belm0]

• fill in Discussions-To
• fix wording of Rationale forward references
• remove use of code-block:: pycon, since it applies a proportional font to >>> and ..., which looks odd and misaligns indents

[AA-Turner]

remove use of code-block:: pycon, since it applies a proportional font to >>> and ..., which looks odd and misaligns indents

I wouldn't do this, as hopefully soon we will move to the Sphinx based system, which doesn't have said problems (https://python.github.io/peps/pep-0682/). Syntactically, code block pycon is also a better expression.

A

[belm0]

remove use of code-block:: pycon, since it applies a proportional font to >>> and ..., which looks odd and misaligns indents

I wouldn't do this, as hopefully soon we will move to the Sphinx based system, which doesn't have said problems (https://python.github.io/peps/pep-0682/). Syntactically, code block pycon is also a better expression.

I see-- though wouldn't in be better to upgrade all PEP's to this new block together, once everything is in place?

By the way, is it OK to share links to https://python.github.io/peps/ now? (e.g. use this in the discussion post rather than https://www.python.org/dev/peps/)

[JelleZijlstra]

I'd suggest you put a brief summary of the PEP (e.g., the abstract, maybe a short code sample) in your Discuss post, so it's easier for people to see at a glance what it's about.

[AA-Turner]

is it OK to share links to https://python.github.io/peps/ now?

Brett, Victor, etc seem to have started doing so -- the canonical link remains /dev/peps, but for Discourse it is slightly more ephemeral, so I'd say go ahead if you'd prefer to.

A

[encukou]

is it OK to share links to https://python.github.io/peps/

In my reading of a link like PEP 682, the number is the stable identifier, and the link URL is just a convenience for the reader. It might as well be PEP 682.
I wouldn't post the link alone, though.

Just don't link to an outdated version like PEP 8 :)

[mdickinson]

LGTM

[belm0]

to summarize:

• the console-specific formatting looks great with the new rendering system for peps.python.org
• however, rendering on the standard pep site is botched. @AA-Turner notes it may be hard to fix. (I'd be happy to help if it's feasible.)
• there is only one other PEP so far using pycon
• it seems we'll need a script to convert console blocks in existing PEP's anyway, so perhaps no need to put this PEP on the bleeding edge

[belm0]

interesting-- the new rendering deduces console blocks anyway

Screen shot after merge of this PR, and confirming other edits are reflected:

[CAM-Gerlach]

As @AA-Turner explained on the other PR, completely nuking the explict .. code-block declaration is not the correct way to fix this. Instead, you should simply change pycon to python to use the standard Python script file syntax highlighting that doesn't have this problem (which is currently the default, but that is an implementation detail that may change) rather than removing it completely.

it seems we'll need a script to convert console blocks in existing PEP's anyway, so perhaps no need to put this PEP on the bleeding edge

There's not so much benefit to doing so on existing PEPs that would justify the noise, except on Active/Process PEPs as they are updated, so long as we keep the default python, and if not then console blocks are no different than any other non-plain-text code block in that regard.

interesting-- the new rendering deduces console blocks anyway

Indeed—my testing also seems to confirm there is no difference when rendered via the new system, at least for these particular (relatively simple) blocks.

[belm0]

Please go ahead and merge. I'll have some upcoming edits from feedback in a subsequent PR.