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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4