[Python-Dev] Bogosities in quopri module?

[Barry A. Warsaw]

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

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
return "hello=09".

The patches must take multiline strings into account though, so that
it doesn't chomp newlines out of

"""hello
great
big
world
"""

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.

Comments?
-Barry