Unrecognized escape sequences in string literals

[Carl Banks]

On Aug 10, 1:37 am, Steven D'Aprano
<ste... at REMOVE.THIS.cybersource.com.au> wrote:
> On Mon, 10 Aug 2009 00:37:33 -0700, Carl Banks wrote:
> > On Aug 9, 11:10 pm, Steven D'Aprano
> > <ste... at REMOVE.THIS.cybersource.com.au> wrote:
> >> On Sun, 09 Aug 2009 18:34:14 -0700, Carl Banks wrote:
> >> >> Why should a backslash in a string literal be an error?
>
> >> > Because the behavior of \ in a string is context-dependent, which
> >> > means a reader can't know if \ is a literal character or escape
> >> > character without knowing the context, and it means an innocuous
> >> > change in context can cause a rather significant change in \.
>
> >> *Any* change in context is significant with escapes.
>
> >> "this \nhas two lines"
>
> >> If you change the \n to a \t you get a significant difference. If you
> >> change the \n to a \y you get a significant difference. Why is the
> >> first one acceptable but the second not?
>
> > Because when you change \n to \t, you've haven't changed the meaning of
> > the \ character;
>
> I assume you mean the \ character in the literal, not the (non-existent)
> \ character in the string.
>
> > but when you change \n to \y, you have, and you did so
> > without even touching the backslash.
>
> Not at all.
>
> '\n' maps to the string chr(10).
> '\y' maps to the string chr(92) + chr(121).
>
> In both cases the backslash in the literal have the same meaning: grab
> the next token (usually a single character, but not always), look it up
> in a mapping somewhere, and insert the result in the string object being
> built.

That is a ridiculous rationalization.  Nobody sees "\y" in a string
and thinks "it's an escape sequence that returns the bytes '\y'".


[snip rest, because an argument in favor inconsistent, context-
dependent behavior doesn't need any further refutation than to point
out that it is an argument in favor of inconsistent, context-dependent
behavior]


Carl Banks