There also seems to be an undercurrent in the discussions we're having now that using bytes paths and not unicode paths is somehow The Right Thing for unix-like OSes,
Almost -- from my perusing of discussions from the last few years, there do seem to be some library developers and *nix affectionados that DO think it's The Right Thing -- after all, a char* has always worked, yes? But these folks also seem to think that a •nix system with no way of knowing what the encoding of the names in the file system (and could have more than one) is not "broken" in any way. A note about "utf-8 everywhere": while maybe a good idea, it's my understanding that *nix developers absolutely do not want utf-8 to be assumed in the Python APIs. Rather, this is all about punting the handling of encodings down to the application level, rather that the OS and Library level. Which is more backward compatible, but otherwise a horrible idea. And very much in conflict with Python 3's approach. So it seems odd to assume utf-8 on Windows, where it is less ubiquitous. Back to "The Right Thing" -- it's clear to me that everyone supporting this proposal is vet much doing so because it's "The Pragmatic Thing". But it seems folks porting from py2 need to explicitly convert the calls from str to bytes anyway to get the bytes behavior. With surrogate escapes, now you need to do nothing. So we're really supporting code that was ported to py3 earlier in the game - but it seems a bad idea to cement that hacks solution in place. And if the file amen in question are coming from a byte stream somehow, rather than file system API calls, then you really do need to know the encoding -- yes really! If a developer wants to assume utf-8, that's fine, but the developer should be making that decision, not Python itself. And not on Windows only. -CHB
and that breaking it (in whatever way) on windows causes code that Does The Right Thing on unix to require extra work to port to windows. That's seemingly both the rationale for the proposal itself and for the objections. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/