(original) (raw)
On Tue, Mar 4, 2014 at 5:23 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
>>>>> Guido van Rossum writes:I don't understand what "support Unicode" means. �Just that
�> Given that the claim "Python 2 doesn't support Unicode filenames"
�> is factually incorrect (in Python 2.7, most filesystem calls in
�> fact do support Unicode, at least on some platforms),
� � with open(u"\\u4e00", "w") as f: f.write("works!\\n")
does what is expected\[1\] if the user knows what he is doing (ie, has
set PYTHONIOENCODING to a Unicode UTF or one of the Asian encodings)?
That's all I'm asking for, since that's what most functions in 2.7 already do.
�
� \> I think individual functions in the os module that are foundAs above, "acceptable fix" means take whatever the current value is
�> lacking should be considered bugs, and if someone goes through
�> the effort to supply an otherwise acceptable fix, we shouldn't
�> reject it on the basis that we don't want to consider supporting
�> Unicode filenames.
for file system name encoding, and use that to encode and decode
unicode objects to/from str, or raise a UnicodeError if it doesn't
work?
The same thing that is done for other functions that take filenames.
I think it's important to define this somewhat carefully, because this
is an area that has a strong tendency to "mission creep". �Given that
builtin open "works" by the above definition, I guess it's reasonable
to accept such patches.
Right, the interpretation given to Unicode filenames by builtin open() should be propagated to other functions (I actually suspect that os.statvfs(), which apparently doesn't, is in the minority here).� AFAIK that's also roughly what happens in Python 3.
Footnotes:
[1] It writes the line "works!\n" to a file whose name consists of the
single Chinese character for "one".
--
--Guido van Rossum (python.org/\~guido)