Issue #3280: like chr() already does, the "%c" format now accepts the full unicode range
even on "narrow Unicode" builds; the result is a pair of UTF-16 surrogates.
diff --git a/Lib/test/test_unicode.py b/Lib/test/test_unicode.py
index 4c81205..fb904bf 100644
--- a/Lib/test/test_unicode.py
+++ b/Lib/test/test_unicode.py
@@ -717,7 +717,10 @@
self.assertEqual("%(x)s, %(\xfc)s" % {'x':"abc", '\xfc':"def"}, 'abc, def')
self.assertEqual('%c' % 0x1234, '\u1234')
- self.assertRaises(OverflowError, "%c".__mod__, (sys.maxunicode+1,))
+ self.assertEqual('%c' % 0x21483, '\U00021483')
+ self.assertRaises(OverflowError, "%c".__mod__, (0x110000,))
+ self.assertEqual('%c' % '\U00021483', '\U00021483')
+ self.assertRaises(TypeError, "%c".__mod__, "aa")
# formatting jobs delegated from the string implementation:
self.assertEqual('...%(foo)s...' % {'foo':"abc"}, '...abc...')