specification

str.upper()¶

Return a copy of the string converted to uppercase.

str.isupper()¶

Return true if all cased characters in the string are uppercase and there is at least one cased character, false otherwise. Cased characters are those with general category property being one of “Lu”, “Ll”, or “Lt” and uppercase characters are those with general category property “Lu”.

>>> '\u1ff3'
'ῳ'
>>> '\u1ff3'.islower()
True
>>> '\u1ff3'.upper()
'ῼ'
>>> '\u1ff3'.upper().isupper()
False
>>>

'\u1ff3'.upper() returns '\u1ffc', so we have:
U+1FF3 (ῳ - GREEK SMALL LETTER OMEGA WITH YPOGEGRAMMENI)
U+1FFC (ῼ - GREEK CAPITAL LETTER OMEGA WITH PROSGEGRAMMENI)
The first belongs to the Ll (Letter, lowercase) category, whereas the second belongs to the Lt (Letter, titlecase) category.

The entries for these two chars in the UnicodeData.txt0 files are:
1FF3;GREEK SMALL LETTER OMEGA WITH YPOGEGRAMMENI;Ll;0;L;03C9 0345;;;;N;;;1FFC;;1FFC
1FFC;GREEK CAPITAL LETTER OMEGA WITH PROSGEGRAMMENI;Lt;0;L;03A9 0345;;;;N;;;;1FF3;

U+1FF3 has U+1FFC in both the third last and last field (Simple_Uppercase_Mapping and Simple_Titlecase_Mapping respectively -- see 1), so .upper() is doing the right thing here.
U+1FFC has U+1FF3 in the second last field (Simple_Lowercase_Mapping), but since it's category is not Lu, but Lt, .isupper() returns False.

The Unicode Standard Annex #442 defines the Lt category as:
Lt Titlecase_Letter a digraphic character, with first part uppercase

I'm not sure there's anything to fix here, both function behave as documented, and it might indeed be the case that .upper() returns chars with category Lt, that then return False with .isupper()

Ezio Melotti wrote:

Ezio Melotti <ezio.melotti@gmail.com> added the comment:

'\u1ff3'.upper() returns '\u1ffc', so we have:
U+1FF3 (ῳ - GREEK SMALL LETTER OMEGA WITH YPOGEGRAMMENI)
U+1FFC (ῼ - GREEK CAPITAL LETTER OMEGA WITH PROSGEGRAMMENI)
The first belongs to the Ll (Letter, lowercase) category, whereas the second belongs to the Lt (Letter, titlecase) category.

The entries for these two chars in the UnicodeData.txt0 files are:
1FF3;GREEK SMALL LETTER OMEGA WITH YPOGEGRAMMENI;Ll;0;L;03C9 0345;;;;N;;;1FFC;;1FFC
1FFC;GREEK CAPITAL LETTER OMEGA WITH PROSGEGRAMMENI;Lt;0;L;03A9 0345;;;;N;;;;1FF3;

U+1FF3 has U+1FFC in both the third last and last field (Simple_Uppercase_Mapping and Simple_Titlecase_Mapping respectively -- see 1), so .upper() is doing the right thing here.
U+1FFC has U+1FF3 in the second last field (Simple_Lowercase_Mapping), but since it's category is not Lu, but Lt, .isupper() returns False.

The Unicode Standard Annex #442 defines the Lt category as:
Lt Titlecase_Letter a digraphic character, with first part uppercase

I'm not sure there's anything to fix here, both function behave as documented, and it might indeed be the case that .upper() returns chars with category Lt, that then return False with .isupper()

I think there's a misunderstanding here: title cased characters
are ones typically used in titles of a document. They don't
necessarily have to be upper case, though, since some characters
are never used as first letters of a word.

Note that .upper() also does not guarantee to return an upper
case character. It just applies the mapping defined in the
Unicode standard and if there is no such mapping, or Python
does not support the mapping, the method returns the
original character.

The German ß is such a character (U+00DF). It doesn't have
an uppercase mapping in actual use and only received such
a mapping in Unicode 5.1 based on rather controversial
grounds (see http://en.wikipedia.org/wiki/ẞ).

The character is normally mapped to 'SS' when converting it
to upper case or title case. This multi-character mapping
is not supported by Python, so .upper() just returns U+00DF.

I suggest to close this ticket as invalid or to add a note
to the documentation explaining how the mapping is applied
(and when not).

A note sounds good.

Here's a patch.
I don't think it's necessary to update the docstring.

New patch that factors out the definition of cased characters adding it to a footnote.

Patch looks good, with one issue: I’ve never encountered “cased character” before, is it an accepted term or an invention in our docs?

I think it's an invention, but its meaning is quite clear to me.

New changeset 16edc5cf4a79 by Ezio Melotti in branch '3.2':
bpo-12204: document that str.upper().isupper() might be False and add a note about cased characters.
http://hg.python.org/cpython/rev/16edc5cf4a79

New changeset fb49394f75ed by Ezio Melotti in branch '2.7':
bpo-12204: document that str.upper().isupper() might be False and add a note about cased characters.
http://hg.python.org/cpython/rev/fb49394f75ed

New changeset c821e3a54930 by Ezio Melotti in branch 'default':
bpo-12204: merge with 3.2.
http://hg.python.org/cpython/rev/c821e3a54930

Fixed, thanks for the report!

Are you sure this should have been backported? Are there any apps that may be working now but won't be after the next point release?

This is only a doc patch, maybe you are confusing this issue with bpo-12266?

Right. I was looking at the other patches that went in in the last 24 hours.

It's unlikely that bpo-12266 might break apps. The behavior changed only for fairly unusual characters, and the old behavior was clearly wrong.
FWIW the str.capitalize() implementation of PyPy doesn't have the bug, and after the fix both CPython and PyPy have the same behavior.