09.08.19 19:39, Steve Dower пише:
I also posted another possible option that helps solve the real problem faced by users, and not just the "we want to have a warning" problem that is purely ours.
Warnings solve two problems: * Teaching users that a backslash has special meaning and should be escaped unless it is used for special meaning. * Avoid breaking or introducing bugs if we add new escape sequences (like \e).
* 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)
It was considered an advantage that these warnings are shown only once at compile time. So they will be shown to the author of the code, but the user of the code will not see them (except of installation time). Actually we need to distinguish the the author and the user of the code and show warnings only to the author. Using .pyc files was just an heuristic: the author compiles the Python code, and the user uses compiled .pyc files. Would be nice to have more reliable way to determine the owning of the code. It is related not only to SyntaxWarnings, but to runtime DeprecationWarnings. Maybe silence warnings only for readonly files and make files installed by PIP readonly?
* change pathlib.PureWindowsPath, os.fsencode and os.fsdecode to explicitly warn when the path contains control characters
This can cause additional harm. Currently you get expected FileNotFound when use user specified bad path, it can be caught and handled. But with warnings you will either get a noise on the output or an unexpected unhandled error.
* 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 do not understand what goal will be achieved by this.