[Python-Dev] Bogosities in quopri module?
Barry A. Warsaw
Mon, 18 Jun 2001 18:28:21 -0400
I've been playing a bit with the quopri module (trying to support RFC
2047 in mimelib), and I've run across a few bogosities that I'd like
to fix. Fixing some of them could break code, so I wanted to see what
people think first.
First, quopri should have encodestring() and decodestring() functions
which take a string and return a string. This would make it more
consistent API-wise with e.g. base64. One difference is that
quopri.encodestring() should probably take a default argument
quotetabs (defaulted to 1) for passing to the encode() function. This
shouldn't be very controversial.
I think there are two problems with encode(). First, it always tacks
on an extra \n character, such that an encode->decode roundtrip is not
idempotent. I propose fixing this so that encode() doesn't add the
extra newline, but this can break code that expects that newline to be
Third, I think that encode()'s quotetabs flag should also apply to
spaces. RFC 1521 says that both ASCII tabs and spaces may be encoded,
and I don't think it's worthwhile that there be a separate flag to
independently choose to encode tabs or spaces.
Lastly, if you buy the extra-newline solution above, then encode() has
to be fixed w.r.t. trailing spaces and tabs. Currently, an
encode->decode roundtrip for, e.g. "hello " returns "hello =\n", but
what it should really return is "hello=20". Likewise "hello\t" should
The patches must take multiline strings into account though, so that
it doesn't chomp newlines out of
I haven't worked up a patch yet, but when I do I'll upload it to SF to
get some feedback. I think there are a few other things in the module
that could be cleaned up. I also plan to add a test_quopri.py.