On Mon, 5 Aug 2019 at 15:44, Facundo Batista <facundobati...@gmail.com> wrote:
>
> El lun., 5 de ago. de 2019 a la(s) 01:25,
> <raymond.hettin...@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#string-checker-messages
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
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/G5EPORSHHEQVQ767II4CWHTXYUGYL4CW/
