Eric V. Smith added the comment: Without lots of analysis (and disassembly), I can't speak to how valid your tests are, but they don't seem unreasonable.
format() will always be slower, because it's more general (primarily in that it can be extended to new types). Plus, it involves at least a name lookup that %-formatting can skip. The usual ways to optimize this lookup holds here, too, if speed is really that critical (which I'm skeptical of). For example, say you had a custom type which implemented __format__ to understand the "X" format code. Using format(), this type could format itself as hex. %-formatting can't do that. In any event, I don't think we want to promulgate the fastest way to do a hex conversion, just the clearest. I can't say why format() in 3.5 is slower. There are many changes and tracking it down would be quite time consuming. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26506> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
