Martin v. Löwis <[EMAIL PROTECTED]> added the comment: > Martin, I cleared the flag bit because filename was changed in-place, to > mark that filename does not need further processing. This was primarily > compatibility concern, to accommodate for situations where users try to > do such decoding in their own code (this way flag won't be there, so > their code won't trigger). Without clearing the flag bit, calling > _decodeFilenameFlags second time will fail, as well as any similar user > code.
I'm not concerned about the compatibility; code that actually does the decoding still might break since it would expect the filename to be a byte string if it doesn't explicitly decode. Such assumption would still break under your change. I am concerned about silently faking data. The library shouldn't do that; it should present the flags unmodified, as some application might perform further processing (such as displaying the flags to the user). It would then be confusing if the data processed isn't the one that was read from disk. > I suggest that if users want to know if filename is unicode, they should > check that filename is of class unicode. That won't work in Py3k, which will always decode the filename. _____________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1734346> _____________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
