This whole thread would be an excellent justification for following 3.9 with 4.0. It's as near as we ever want to get to a breaking change, and a major version number would indicate the need to review. If increasing strictness of escape code interpretation in string literals is the only incompatibility there would surely be general delight. Kind regards, Steve Holden On Wed, Aug 7, 2019 at 8:19 PM eryk sun <eryksun@gmail.com> wrote:
On 8/7/19, Steve Dower <steve.dower@python.org> wrote:
* change the PyErr_SetExcFromWindowsErrWithFilenameObjects function to append (or chain) an extra message when either of the filenames contains
c
control characters (or change OSError to do it, or the default sys.excepthook)
On a related note for Windows, if the error is specifically ERROR_INVALID_NAME, we could extend this to look for and warn about the five reserved wildcard characters (asterisk, question mark, double quote, less than, greater than), pipe, and colon. It's only sometimes the case for colon because it's allowed in device names and used as the name and type delimiter for stream names.
Kernel object names don't reserve wildcard characters, pipe, and colon. So I wouldn't want anything but the control-character warning if it's say ERROR_FILE_NOT_FOUND. An example would be SharedMemory(name='Global\test'), or a similar error for registry key and value names such as OpenKey(hkey, 'spam\test'), that is if winreg were updated to include the name in the exception. Note that forward slash is just a name character in these cases, not a path separator, so we have to use backslash, even if just via replace('/', '\\'). _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/UFMVFL4Q...