GeezerVison

This feels too low-level for the SC to decide, unless you have concrete indications that it's something they're concerned about. I'd prefer if the PEP takes a concrete stance, otherwise it just becomes something that can drag out the discussion. (I don't want another PEP 646.)

I'd prefer if the PEP takes a concrete stance

Makes sense. I'll add the concrete stance we've agreed on and remove this offer.

(I don't want another PEP 646.)

Too soon, Jelle. Too soon :)

Is there a reason this was reverted? It is simpler and more reliable to use :pep: to refer to PEPs rather than hardcoding the full absolute URL, and will allow us to do things like show the PEP's title in the titletext and other things in the future.

@CAM-Gerlach can we add a lint check for this? It could probably look for python.org/dev/peps with a whitelist of ones we don't want to change [yet] (a few in 1,12,287 from memory).

A

Is there a reason this was reverted? It is simpler and more reliable to use :pep: to refer to PEPs rather than hardcoding the full absolute URL, and will allow us to do things like show the PEP's title in the titletext and other things in the future

Huh. The official PEP page renders the :pep: link correctly but the GitHub "View file" Markdown preview doesn't. I was going by the latter. Will revert back to the :pep: version.

can we add a lint check for this? It could probably look for python.org/dev/peps with a whitelist of ones we don't want to change [yet] (a few in 1,12,287 from memory).

Good idea; in work. If/when PEP 676 is accepted and we transition to the Sphinx-based infra, we could also add one for hardcoded links to PEP supplementary files, instead of using :download: (or another appropriate role)—unless you have a good way to do this now that works across both the legacy and new build systems and doesn't break when changing the output mode (files/directories/etc).

Huh. The official PEP page renders the :pep: link correctly but the GitHub "View file" Markdown preview doesn't. I was going by the latter. Will revert back to the :pep: version.

The GitHub Markdown preview only has very limited compatibility with RST syntax and should never be relied upon; we will have rendered previews on PRs soon assuming PEP 676 is accepted (or possibly before, depending on when @AA-Turner adds it). Until then, please follow the instructions in the Readme/Contributing guide (basically, install the requirements.txt then run the build.py script for the new build system or the pep2html.py one for the old one to build a preview.

Don't know if that's the right place for it to ask.

Instead of overloads, wouldn't it also work / be better to use a bound TypeVar or the new Self type? The way I understand the PEP, LiteralString should be defined as subtype of str within typeshed.

From the PEP:

Rationale

[...] LiteralString is the "supertype" of all literal string types.
In effect, this PEP just introduces a type in the type hierarchy
between Literal["foo"] and str. [...]

A TypeVar wouldn't work for this case, sadly, as the relationship here doesn't generalise to other subtypes of str:

>>> class Foo(str): ...
... 
>>> Foo('hi')
'hi'
>>> type(_)
<class '__main__.Foo'>
>>> Foo('hi').capitalize()
'Hi'
>>> type(_)
<class 'str'>

I think a TypeVar with constraints (similar to AnyStr) might work?

Hmm — that might work, but might also run into mypy bugs similar to python/typeshed#6762?

Don't know if that's the right place for it to ask.

@cdce8p You could also bring it up on the official typing-sig thread for this PEP, which appears to be this one—that might be more generally visible than a comment on a merged PR, if you're looking for a wider discussion.

On a more editorial note, it looks like the PEP hasn't yet been updated with the link to the actual discussion thread, which I only found after a fair amount of determined digging (and guessing). I'll open a PR to add that.