Alas, Guido and I have the same ISP (@home), and its mail server has been dead all day. Conveniently <snort>, my other ISP (MSN) coincidentally stopped letting me send email over my cable connection too. [Guido]

I just skimmed the pipermail python-dev archives and found one item to pronounce on: what "%o" should do with negative longs. I agree with Tim. Also for "%x". Reason: this matches oct() and hex().

Good point!

...

...

...

oct(-10L) '-012L' oct(-10) '037777777766'

Note that this string varies across platforms.

...

...

...

hex(-10L) '-0xAL' hex(-10) '0xfffffff6'

Ditto.

...

...

...

Compatibility be damned (in this case).

This became SF bug 123859, and has been closed. Current CVS does:

...

...

"%#o" % -10L '-012' "%#X" % -10L '-0XA'

(One could argue that for plain ints, the same result are desirable; however when these are used as bitmasks, I as human reader prefer to see '0xfffffff6' rather than '-0xA'. Ah the insanity of consistency!)

I doubt that we're done with this forever: we're moving in the direction of erasing user-visible distinctions between ints and longs. For bitmask output, we should probably introduce a new format code. Fred, I see that you complained about Finn's output examples, but didn't say why (just "they both look incorrect"). Were you hallucinating, or do you have a legit complaint?

Alas, Guido and I have the same ISP (@home), and its mail server has been dead all day. Conveniently <snort>, my other ISP (MSN) coincidentally stopped letting me send email over my cable connection too. [Guido]

I just skimmed the pipermail python-dev archives and found one item to pronounce on: what "%o" should do with negative longs. I agree with Tim. Also for "%x". Reason: this matches oct() and hex().

Good point!

...

...

...

oct(-10L) '-012L' oct(-10) '037777777766'

Note that this string varies across platforms.

...

...

...

hex(-10L) '-0xAL' hex(-10) '0xfffffff6'

Ditto.

...

...

...

Compatibility be damned (in this case).

This became SF bug 123859, and has been closed. Current CVS does:

...

...

"%#o" % -10L '-012' "%#X" % -10L '-0XA'

(One could argue that for plain ints, the same result are desirable; however when these are used as bitmasks, I as human reader prefer to see '0xfffffff6' rather than '-0xA'. Ah the insanity of consistency!)

I doubt that we're done with this forever: we're moving in the direction of erasing user-visible distinctions between ints and longs. For bitmask output, we should probably introduce a new format code. Fred, I see that you complained about Finn's output examples, but didn't say why (just "they both look incorrect"). Were you hallucinating, or do you have a legit complaint?