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.
Jonathan Goble