I think there are too many risks with this approach, especially given that we're keeping % formatting mainly for backwards compatibility reasons. There will inevitably be corner cases where the conversion doesn't work exactly the same way as the old code or where the conversion is wrong for whatever reason, and it would be quite painful to change back.
If 2.6 can't support %b, so be it. On Wed, Apr 9, 2008 at 4:54 PM, Eric Smith <[EMAIL PROTECTED]> wrote: > I'm working on issue 2416, adding %b to % formatting > (http://bugs.python.org/issue2416). It's really quite a pain, > especially in 2.6 with int and long and str and unicode. > > I'm contemplating just making % formatting compute a new format string > and call str.format (or obj.__format__, or something appropriate). But > before I proceed, I thought I'd ask and see if this really offends > anyone. By implementing % in terms of str.format, I hope to be able to > delete a lot of the duplication in the formatting code, but I haven't > checked yet to see what's possible. The real impetus is issue 2416, though. > > About the only downside I see is that str.format is somewhat slower than > %, but I can probably get around most of this by directly calling > int.__format__, float.__format__, etc. Other than misleading > microbenchmarks, I've never really compared the difference, though. > > _______________________________________________ > Python-3000 mailing list > Python-3000@python.org > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com