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 vstinner
Recipients doerwalter, eric.smith, ezio.melotti, vstinner
Date 2010-03-10.00:25:42
SpamBayes Score 9.569831e-09
Marked as misclassified No
Message-id <1268180745.69.0.520353307834.issue7267@psf.upfronthosting.co.za>
In-reply-to
Content
u'{0:c}'.format(256) formatter in implemented in Objects/stringlib/formatter.h and this C template is instanciated in... Python/formatter_string.c (and not Python/formatter_unicode.c). Extract of formatter_unicode.c comment:

/* don't define FORMAT_LONG, FORMAT_FLOAT, and FORMAT_COMPLEX, since
   we can live with only the string versions of those.  The builtin
   format() will convert them to unicode. */

format_int_or_long_internal() is instanciated (only once) with STRINGLIB_CHAR=char and so "numeric_char = (STRINGLIB_CHAR)x;" becomes "numeric_char = (char)x;" whereas x is a long in [0; 0x10ffff] (or [0; 0xffff] depending on Python unicode build option).

I think that 'c' format type should have its own function because 
format_int_or_long_internal() gets locale info, compute the number of digits, and other things not related to just creating one character from its code (chr(code) / unichr(code)). But it's just a remark, it doesn't fix this issue.

To fix this issue, I think that the FORMAT_LONG & cie templates should be instanciated twice (str & unicode).
History
Date User Action Args
2010-03-10 00:25:45vstinnersetrecipients: + vstinner, doerwalter, eric.smith, ezio.melotti
2010-03-10 00:25:45vstinnersetmessageid: <1268180745.69.0.520353307834.issue7267@psf.upfronthosting.co.za>
2010-03-10 00:25:42vstinnerlinkissue7267 messages
2010-03-10 00:25:42vstinnercreate