Am 19.08.14 19:43, schrieb Ben Hoyt: >>>> The official policy is that we want them [support for bytes paths in >>>> stdlib functions] to go away, but reality so far has not budged. We will >>>> continue to hold our breath though. :-) >>> >>> Does that mean that new APIs should explicitly not support bytes? I'm >>> thinking of os.scandir() (PEP 471), which I'm implementing at the >>> moment. I was originally going to make it support bytes so it was >>> compatible with listdir, but maybe that's a bad idea. Bytes paths are >>> essentially broken on Windows. >> >> Bytes paths are "essential" on Unix, though, so I don't think we should >> create new low-level APIs that don't support bytes. > > Fair enough. I don't quite understand, though -- why is the "official > policy" to kill something that's "essential" on *nix?
I think the people defending the "Unix file names are just bytes" side often miss an important detail: displaying file names to the user, and allowing the user to enter file names. A script that just needs to traverse a directory tree and look at files by certain criteria can easily do so with not worrying about a text interpretation of the file names. When it comes to user interaction, it becomes apparent that, even on Unix, file names are not just bytes. If you do "ls -l" in your shell, the "system" (not just the kernel - but ultimately the terminal program, which might be the console driver, or an X11 application) will interpret the file name as having an encoding, and render them with a font. So for Python, the question is: which of the use cases (processing all files, vs. showing them to the user) should be better supported? Python 3 took the latter as an answer, under the assumption that this is the more common case. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com