This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients kalt, loewis, snaury
Date 2008-05-05.21:15:59
SpamBayes Score 0.0010460156
Marked as misclassified No
Message-id <481F790D.8030206@v.loewis.de>
In-reply-to <1210012813.49.0.493278881137.issue1734346@psf.upfronthosting.co.za>
Content
> 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.
History
Date User Action Args
2008-05-05 21:16:04loewissetspambayes_score: 0.00104602 -> 0.0010460156
recipients: + loewis, snaury, kalt
2008-05-05 21:16:03loewislinkissue1734346 messages
2008-05-05 21:16:02loewiscreate