binascii.b2a_qp oddities

[dsm001]

BPO	1085283
Nosy	@birkenfeld

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2007-03-13.22:51:17.000>
created_at = <Date 2004-12-14.18:11:48.000>
labels = ['library']
title = 'binascii.b2a_qp oddities'
updated_at = <Date 2007-03-13.22:51:17.000>
user = 'https://bugs.python.org/dsm001'

bugs.python.org fields:

activity = <Date 2007-03-13.22:51:17.000>
actor = 'georg.brandl'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2004-12-14.18:11:48.000>
creator = 'dsm001'
dependencies = []
files = []
hgrepos = []
issue_num = 1085283
keywords = []
message_count = 2.0
messages = ['23706', '23707']
nosy_count = 2.0
nosy_names = ['georg.brandl', 'dsm001']
pr_nums = []
priority = 'low'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1085283'
versions = []

[dsm001]

[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.

[birkenfeld]

Fixed (1) and (3) in rev. 54367. I think (2) is not important enough to do anything about it.