Issue 1085283: binascii.b2a_qp oddities - Python tracker (original) (raw)

[Python 2.5a0 (#9, Dec 8 2004, 12:37:01); the behaviours go way back.]

binascii.b2a_qp has several quirks discovered when reimplementing.

(1) It lets low bytes pass through unescaped -- e.g. binascii.b2a_qp('\x08') == '\x08' -- unless quotetabs is True. This looks to be an error in program logic at lines ~1165 and ~1234, unless this is intended (although quopri's internal version quotes them). This doesn't seem RFC 1521 compatible on my reading of section 5 (admittedly I only read it for the first time last week. :-)

(2) It determines whether to enforce \n or \r\n by scanning the string for the first occurrence [which should be mentioned in the docs]. binascii.c does this by calling strchr, which stops at the first \x00.

This means that:

s0 = "The quick " + chr(0) + "brown fox.\r\n" s1 = "The quick " + chr(1) + "brown fox.\r\n" binascii.b2a_qp(s0) 'The quick \x00brown fox.\n' binascii.b2a_qp(s1) 'The quick \x01brown fox.\r\n'

and related strangenesses.

(3) The code escapes the period "." if and only if it's the second character in a line. I'm not sure why; the only mention I can find in 1521 is in appendix B of escaping a period ALONE on a line in some situations, which binascii.b2a_qp doesn't do in any event. This behaviour may be prescribed by some other spec but is strange enough to be mentioned in the docs if it's intentional.

A new strictly RFC1521-compliant qp encoding would be a good thing if backwards compatibility prevents changing some of these.