PEP 822: d-string draft implementation

[methane]

Discourse thread: https://discuss.python.org/t/pep-822-dedented-multiline-string-d-string/105519

PEP PR (not merged yet): python/peps#4768

[picnixz]

Hi Methane. I know you're a core dev, but usually we don't open PRs for pre-PEPs (and prefer authors to keep them in their fork or a separate repository) until the SC has given approval. Could you do it please?

[methane]

Oh, I'm sorry. I used PR to write "Reference Implementation" section in the PEP.
I didn't use branch in my fork because I regularly clean up unused branches.
If I delete the d-string branch, "Reference Implementation" link in the PEP become dead link.

I reviewed the PEP guidelines but could not determine whether it is preferable to use a branch or a PR as the URL for the reference implementation, nor whether it is acceptable for the reference implementation URL to become a dead link after the PEP has been finalized.

I was planning to change the PR title from Pre-PEP to PEP NNN in a few days, but should I close this PR and take a different approach?

[picnixz]

If I delete the d-string branch, "Reference Implementation" link in the PEP become dead link.

I'd advise you to keep the branch even if it becomes stale. What I meant is that it's preferrable that you don't keep an open PR especially if it's about "pre-PEP".

The reason why I asked not to open a PR is because we tend to have many stale PRs. If you believe that the PEP is likely to be accepted, I guess we could keep it (there are some precedents where other core devs opened draft PRs just for the reference implementation such as for PEP-791). Other PEPs such as PEP-810 had another fork that was only for that PEP so that (1) CI was available to them (2) discussion could be centralized.

whether it is acceptable for the reference implementation URL to become a dead link after the PEP has been finalized.

I would be a bit unfortunate I think and I think the approach taken by https://peps.python.org/pep-0810/#reference-implementation is probably the safest, though I don't know whether you like having "stale" repositories (the advantage is you can archive it after it has been finalized, whether it's accepted or rejected).