Please don't break invalid escape sequences

[jagerber (Justin Gerber)]

@bavalpey

@bavalpey

@pf_moore

The point has been made that this enables future changes like making \e an escape character. That would be a small but positive benefit for many Python users. We could just make that change without this deprecation, but if we did so, that would also break your code,

With all due respect, in the case of docstrings, no, this would not break the code. Please stop claiming it would.

…

@bavalpey

But this wouldn’t break the code. It would break comment. The core library functionality would continue to work.

I find this line of conversation confusing. Not sure what you mean by “in the case of docstrings, no, this would not break the code”. By this do you mean this change would not break the docstring? It your next post it sounds like you agree that this change WOULD break the docstring (“It would break comment”). This is exactly what Umar was addressing.

We are consider the case where

• No SyntaxError is ever raised in the case of invalid escape characters
• a new escape character \e is introduced into python between versions 3.A and 3.B

Now suppose a user has the string print("H\ello World") in their source code. The output of this code would differ between versions 3.A and 3.B. I think everyone would agree that the introduction of the new escape character broke this user’s code.

Now suppose the user has a docstring of the form """...d\e...""". Umar has pointed out that IDE tools that render docstrings will render this docstring different between version 3.A and 3.B. I think it is fair to say that this change has broken the docstring. To understand this we have to remember the docstrings are python objects, as explored more thoroughly in this thread.

So I would say that (in this hypothetical), the introduction of new escape characters has the potential to break both code and docstrings.