On Mon, 5 Aug 2019 at 15:44, Facundo Batista <facundobatista@gmail.com> wrote:
El lun., 5 de ago. de 2019 a la(s) 01:25, <raymond.hettinger@gmail.com> escribió:
We should revisit what we want to do (if anything) about invalid escape sequences.
For Python 3.8, the DeprecationWarning was converted to a SyntaxWarning which is visible by default. The intention is to make it a SyntaxError in Python 3.9.
What about allowing in 3.8 to from __future__ import this SyntaxWarning (so anybody can start kicking own code's tires), then 3.9 could make it a real SyntaxWarning, and 4.0 (3.10?) make it a SyntaxError?
Do existing linters flag suspicious/incorrect use of escapes? Could (or should) they? I suspect that a future import will be used by a lot fewer projects than would benefit from this being flagged by linters. Hmm, it looks like linters do flag this: pycodestyle (used by flake8) - https://pep8.readthedocs.io/en/latest/intro.html#error-codes pylint - https://pylint.readthedocs.io/en/latest/technical_reference/features.html#st... This begs the question why libraries haven't already fixed this :-(
Of course, in a year or so we could decide to delay the last two steps even more...
It's way too easy to simply get into a cycle of repeatedly delaying something like this. IMO the only point in delaying the switch to a SyntaxWarning would be if there were a way to encourage libraries to fix the problem in the extra time before the switch occurred (to minimise the effect on end users). But from the look of it, that's not going to happen - even linter warnings don't seem to make much difference there :-( So I don't see that a delay (or a future import) would actually help much. But I still suspect that we're in for a painful period where users get warnings from libraries that haven't been fixed. All of the above ignores the question of whether we should make invalid escapes generate a (visible) warning. I've seen enough errors caused by the "false positives" (\U or \n in Windows filenames, for example) that I'm inclined to be strict (even though I accept that strictness hits "false negatives" rather than "false positives"). And I really don't see why it's so hard to fix code - use raw strings for docstrings, and for Windows filenames, and always double backslashes in "simple" strings unless you know you mean to use an escape. And use a linter to check when you make a typo! Paul