Trying again after I was mysteriously moderated. Thanks Ethan for fixing that. On Sat, May 28, 2022 at 6:59 PM Jonathan Goble <jcgoble3@gmail.com> wrote:

On Sat, May 28, 2022, 4:25 PM Gregory P. Smith <greg@krypto.org> wrote:

...

On Sat, May 28, 2022 at 12:55 PM Guido van Rossum <guido@python.org> wrote:

...

On Sat, May 28, 2022 at 12:11 MRAB

Names in Python are case-sensitive, yet the string prefixes are

...

case-/insensitive/.

Why?

IIRC we copied this from C for numeric suffixes (0l and 0L are the same; also hex digits and presumably 0XA == 0xa) and then copied that for string prefixes without thinking about it much. I guess it’s too late to change.

Given that 99.99% of code uses lower case string prefixes we *could* change it, it'd just take a longer deprecation cycle - you'd probably want a few releases where the upper case prefixes become an error in files without a `from __future__ import case_sensitive_quote_prefixes` rather than jumping straight from parse time DeprecationWarning to repurposing the uppercase to have a new meaning. The inertia behind doing that over the course of 5+ years is high. Implying that we'd need a compelling reason to orchestrate it. None has sprung up.

There already is a semantic meaning in one case, though not in Python proper. Some syntax highlighters, including the one used in VSCode, treat r and R differently: the former is syntax highlighted as a regex and the latter is syntax highlighted as an generic string. I have seen project-specific style guides advising to use r/R accordingly.

So there is meaningful use of capital R in real-world code, and any future change to require lowercase would need to at least consider the impact on that use case.

...