On 07Aug2019 0247, Chris Angelico wrote:
On Wed, Aug 7, 2019 at 7:33 PM Steven D'Aprano <steve@pearwood.info> wrote:
What's the rush? Let's be objective here: what benefit are we going to get from this change? Is there anyone hanging out desperately for "\d" and "\-" to become SyntaxErrors, so they can... do what?
So that problems can start to be detected. Time and again, Python users on Windows get EXTREMELY confused by the way their code worked perfectly with one path, then bizarrely fails with another. That is a very real problem, and the problem is that it appeared to work when actually it was wrong. [...] If you can offer a better plan, then by all means, do so. But deferring without a change is of no real value, and it means ANOTHER eighteen months added onto the time before novice programmers get to be told about string literal problems.
Allow me to offer one: * change the SyntaxWarning into a default-silenced one that fires every time a .pyc is loaded (this is the hard part, but it's doable) * change pathlib.PureWindowsPath, os.fsencode and os.fsdecode to explicitly warn when the path contains control characters * change the PyErr_SetExcFromWindowsErrWithFilenameObjects function to append (or chain) an extra message when either of the filenames contains control characters (or change OSError to do it, or the default sys.excepthook) I don't care whether the changes are applied to all platforms rather than just Windows, but since Windows developers hit the problem and (some) Linux developers like to use control characters in filenames, I can see a justification for only warning on Windows. Long term we can still deprecate and eventually block unrecognized escape sequences, but the long standing behaviour can stand for a few more years without creating more harm. Cheers, Steve