r'\' - python parser bug?

[Tim Peters]

[Konstantin Veretennicov, on raw strings]
>>> Should i submit a bug report to development?

[Tim]
>> Nope:  it's not a bug, and won't change.

[Konstantin]
> Ok. Does it mean i'm not encouraged to even try inventing a patch?

If your purpose in inventing the patch would be to get it accepted into the
language, it will be rejected (of course you're not the first person to
notice this -- it's a FAQ!  The "no trailing odd number of backslashes"
business was known before raw strings were introduced, Guido was happy with
that, and has explicitly rejected all attempts to change it.).  There are
also many reasons you might want to work up a patch without caring whether
it's accepted (curiosity, education, experimentation, hubris <wink>, ...).

> It won't break anything, or will it?

Yup.  Right now all tools (including Python itself) that scan over strings
in Python source can (and usually do) treat backslashes identically, whether
in loops or in regexps.  If this is changed, you also need to change all
such tools to match (including things like the Emacs Python mode, IDLE's
parser, tokenize.py, and on & on).  It's not *just* the Python compiler that
believes r'\' is an unterminated string now.

> I agree we can live without r'\', but are there any reasons *against*
> r'\'?

Yes:  it would be an expensive and disruptive change, because it would
affect so many programs.  It's also opposed to the *purpose* of r-strings:
they were introduced to ease creating input for functions and programs that
want to do their own backslash escape processing, chiefly for
regexp-slinging consumers.  Input with an odd number of trailing backslashes
makes no sense to them, so there's no need for r-strings to support such a
thing.