R. David Murray <rdmur...@bitdance.com> added the comment: This bug is more subtle than it first appears. As far as I've been able to figure out, there is in fact no way to reliably detect that there is non-format text after the format specifier short of completely parsing the format specifier. I went through several possibilities and found a counter example for each that shows it would introduce new bugs:
See if last character of formatted string is different from last char of formatter: format('%s', 'things') would then incorrectly be an error. Make sure last character of format string is a valid format character: format('%fx', a) would be valid, but it has a 'x' on the end which is not part of the format string. (The suggested patch has a false negative in this case as well.) Check for a decimal in the formatted string and if it didn't get transformed, complain: format('%s', '1.234') would fail incorrectly. One could argue that at least \n and \r should be checked for since the output from those cases is least obviously "wrong", but I don't think that is a strong argument. The extra control character is almost as "visible" in the output as the trailing 'x' would be in the above example, and the effects of the trailing x are equally mysterious. To fix this correctly would require reimplementing format parsing in the locale module, which would be a maintenance headache. I'm inclined to close this "won't fix", unless someone can come up with a heuristic that won't give false positives or false negatives. ---------- nosy: +bitdancer resolution: -> wont fix stage: -> committed/rejected status: open -> pending versions: +Python 2.7, Python 3.0, Python 3.1 -Python 2.5 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue2522> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com