Mailing List Archive

Re: [OT] Re: Raw strings ending with a backslash
On 2022-05-28 16:03, MRAB wrote:
> On 2022-05-28 13:17, Serhiy Storchaka wrote:
>> 28.05.22 14:57, Damian Shaw ????:
>>> That PR seems to make \' and \" not special in general right?
>>>
>>> I think this is a more limited proposal, to only change the behavior
>>> when \ is at the end of a string, so the only behavior difference would
>>> never receiving the error "SyntaxError: EOL while scanning string literal"
>>>
>>> In which case there should be no backwards compatibility issue.
>>
>> How do you know that it is at the end of a string?
>>
> It would also affect triple-quoted strings.
>
> Here's an idea: prefix rr ("really raw") that would treat all
> backslashes literally.
> Here's something I've just realised.

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

Why?
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/3FZJWRIZQQDNMJYJ2SOZFW3R7NVHKNC4/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [OT] Re: Raw strings ending with a backslash [ In reply to ]
On Sun, 29 May 2022 at 05:05, MRAB <python@mrabarnett.plus.com> wrote:
>
> On 2022-05-28 16:03, MRAB wrote:
> > On 2022-05-28 13:17, Serhiy Storchaka wrote:
> >> 28.05.22 14:57, Damian Shaw ????:
> >>> That PR seems to make \' and \" not special in general right?
> >>>
> >>> I think this is a more limited proposal, to only change the behavior
> >>> when \ is at the end of a string, so the only behavior difference would
> >>> never receiving the error "SyntaxError: EOL while scanning string literal"
> >>>
> >>> In which case there should be no backwards compatibility issue.
> >>
> >> How do you know that it is at the end of a string?
> >>
> > It would also affect triple-quoted strings.
> >
> > Here's an idea: prefix rr ("really raw") that would treat all
> > backslashes literally.
> > Here's something I've just realised.
>
> Names in Python are case-sensitive, yet the string prefixes are
> case-/insensitive/.
>
> Why?

Technically they're not, but there are aliases. Kinda like
threading.currentThread().

ChrisA
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7PCCF24SSFJQKPA46PGF52XTROQM3QYT/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [OT] Re: Raw strings ending with a backslash [ In reply to ]
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.

—Guido
--
--Guido (mobile)
Re: [OT] Re: Raw strings ending with a backslash [ In reply to ]
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.

-gps


> —Guido
> --
> --Guido (mobile)
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/27HLMPDURSAN2YCTFWN6LETWQNY4POX7/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
Re: [OT] Re: Raw strings ending with a backslash [ In reply to ]
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.
>
>>