Antoine Pitrou wrote:
Vinay Sajip <vinay_sajip <at> yahoo.co.uk> writes:
"%0#8x" % 0x1234 '0x001234' "{0:0>#8x}".format(0x1234) '000x1234'
Apart from the sheer unreadability of the {}-style format string, the result looks rather unexpected from a human being's point of view.
The percent format string is pretty unreadable too - you're just more used to it, so it doesn't look as weird :) Vinay's problem above is due to using the wrong alignment flag: ">", which says to right align everything, instead of "=", which says to left align the sign character and the numeric prefix with the fill character inserted in the middle. In this particular case he could also use the zero-padding shortcut which leaves out the alignment flag altogether (and implies a "0=" alignment format). That is (using 2.6/3.1):
"%#08x" % 0x1234 '0x001234' "%0#8x" % 0x1234 '0x001234' "{0:#08x}".format(0x1234) '0x001234' "{0:0>#8x}".format(0x1234) '000x1234' "{0:0=#8x}".format(0x1234) '0x001234'
Adding in the sign bit gives the following translations:
"%+#08x" % 0x1234 '+0x01234' "%+0#8x" % 0x1234 '+0x01234' "{0:+#08x}".format(0x1234) '+0x01234' "{0:0>+#8x}".format(0x1234) '0+0x1234' "{0:0=+#8x}".format(0x1234) '+0x01234'
Note that ">" alignment is actually now *broken* on trunk and py3k, since ">" and "=" are now behaving exactly the same instead of the former right aligning the entire number including the sign bit and prefix:
"{:0>+8x}".format(0x1234) '+0001234' "{:0=+8x}".format(0x1234) '+0001234'
(bug assigned to Eric: http://bugs.python.org/issue7081) Note that, since percent formatting doesn't allow specification of the fill characters or the field alignment, translations should probably rely on the simple field width specifier, optionally selecting zero padding by preceding it with a zero. It should never be necessary to use the full alignment spec for translated formats. The other thing to keep in mind is that brace formatting is fussier about the order of things - items *must* appear in the order they are listed in PEP 3101 (i.e. if wanting a zero padded field with leading sign and numeric prefix, you must write "+#0"). Percent format, on the other hand, allows the "#", "+" and "0" to be placed in any order you like (although they must appear before the field width definition, precision specifier and type code). As far as I can see, that leaves the prefixing of octal numbers ("0o" vs "0") as the only true incompatibility between percent formatting and brace formatting, and even for those the incompatibility is limited to cases where a field width is specified without leading zeroes or a sign character is specified. In other cases, the translation can just stick a leading literal "0" in front of the field in the brace formatting string. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------