Encoding updates#703
Conversation
|
Great! I am completely for dropping Python 2.7. Even 3.4 and 3.5 if needed, by it seems not for now :) Could you add lines in the changelog + your GH nickname? Also if you mind updating the README and/or just remove Python 2.7 everywhere (I could do it before the release though). I will merge tomorrow, thanks for the patch 💪 |
|
Will do. The Python 2.7 tests are predictably failing but also some Python 3.10 and Windows tests. From a brief glance, it doesn't look like anything introduced in this PR. Before you merge, I'll also add an emitter test with invalid bytes in the filename. Just in case people are tempted to use |
7267a8d to
d9e8654
Compare
|
Ok, this should be ready now. The remaining test failures are:
I am mostly concerned about the second one. Could this have anything to do with the changes from this PR? |
|
1 and 3 are OK. |
|
Passed, I wil merge after the nitpick in the test. |
|
Thanks a lot @samschott :) |
|
Thanks for merging -- and for the very quick response times! |
Unfortunately gorakhargosh#703 cannot easily be backported, so we won't have this functionality in the Python 2.7 / 3.5 branch unless someone reports this as an issue.
This PR changes how paths are encoded and decoded on Unixes as follows:
os.fsencodeandos.fsdecodefunctions available from 3.2.Those changes have significant advantages when creating the watches with a
strpath. Previously, events from paths which contain bytes that cannot be decoded in the file system encoding (sys.getfilesystemencoding()) would raise an unhandledUnicodeEncodingErrorin the inotify emitter thread. Now, the bytes are converted to Python's "surrogate escapes" and remain in the string. Allosfunctions accept strings with such "escaped bytes" and will properly convert them back withos.fsencode.