You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
string.Formatter returns str for empty unicode template #60155
Expected behavior of string.Formatter() is to return unicode strings for unicode templates, and "byte" strings for str templates. Which is exactly what it does, with one frustrating exception: for empty unicode string it returns byte str. Test follows:
"In all cases, the type of the format string dominates - that
is, the result of the conversion will always result in an object
that contains the same representation of characters as the
input format string."
I filed bpo-15952 for the behavior difference between format(value) and value.__format__() and the related lack of documentation re: unicode format strings.
Given that the expected behavior for the current issue doesn't seem to be documented (aside from PEP-3101, which is probably too late to follow), we should probably agree on what the behavior should be (as well as documenting it) before or while addressing this issue.
Some explanation behind the patch that stems from the above comments:
The following is an example of Formatter.format() returning str in the current implementation that would break if we made Formatter.format() return unicode whenever format_string is unicode:
(It would break with a UnicodeDecodeError because 'ascii' is the default encoding.)
Since we can't change Formatter.format(format_string) to return unicode whenever format_string is unicode without breaking existing code, I believe the best we can do is to document the departure from PEP-3101. Since the caller has to handle return values of type str anyways, I don't think it helps to ensure that more return values are unicode.
Activity
AlekseySivokon commentedon Sep 16, 2012
Expected behavior of string.Formatter() is to return unicode strings for unicode templates, and "byte" strings for str templates. Which is exactly what it does, with one frustrating exception: for empty unicode string it returns byte str. Test follows:
cjerdonek commentedon Sep 16, 2012
Adding failing test. Patch coming next.
cjerdonek commentedon Sep 16, 2012
Here are some related failing cases that I found:
Note that PEP-3101 says the following:
"In all cases, the type of the format string dominates - that
is, the result of the conversion will always result in an object
that contains the same representation of characters as the
input format string."
cjerdonek commentedon Sep 16, 2012
Actually, I'm going to defer on creating a patch because this covers more scenarios than I originally thought and so may require more time.
bitdancer commentedon Sep 16, 2012
Format with unicode is a bit of a mess in 2.7. It would be consistent with the rest of python2 for
>>> f.format("{0}", u"a") u'a'to be correct.
See also bpo-7300 and bpo-15276.
cjerdonek commentedon Sep 16, 2012
What about cases like this?
It seems fixing this issue for non-empty strings would cause formerly running cases like this to raise UnicodeDecodeError.
Would that be acceptable?
bitdancer commentedon Sep 16, 2012
Note that I didn't say it was correct, I just said it was consistent :)
And no, breaking stuff that current works is a non-starter for 2.7.
cjerdonek commentedon Sep 16, 2012
I filed bpo-15952 for the behavior difference between format(value) and value.__format__() and the related lack of documentation re: unicode format strings.
Given that the expected behavior for the current issue doesn't seem to be documented (aside from PEP-3101, which is probably too late to follow), we should probably agree on what the behavior should be (as well as documenting it) before or while addressing this issue.
cjerdonek commentedon Sep 19, 2012
Attached is a proposed patch.
Some explanation behind the patch that stems from the above comments:
The following is an example of Formatter.format() returning str in the current implementation that would break if we made Formatter.format() return unicode whenever format_string is unicode:
(It would break with a UnicodeDecodeError because 'ascii' is the default encoding.)
Since we can't change Formatter.format(format_string) to return unicode whenever format_string is unicode without breaking existing code, I believe the best we can do is to document the departure from PEP-3101. Since the caller has to handle return values of type str anyways, I don't think it helps to ensure that more return values are unicode.