barry.warsaw wrote:
- # Header's got lots of smarts, so use it. + # Header's got lots of smarts, so use it. Note that this is + # fundamentally broken though because we lose idempotency when + # the header string is continued with tabs. It will now be + # continued with spaces. This was reversedly broken before we + # fixed bug 1974. Either way, we lose. print >> self._fp, Header( - v, maxlinelen=self._maxheaderlen, - header_name=h, continuation_ws='\t').encode() + v, maxlinelen=self._maxheaderlen, header_name=h).encode() # A blank line always separates headers from body print >> self._fp
How do we get idempotency back in 3.0? I know we talked about a Header class registry and always using Header objects, but jetlag has rotted my brain as to when and how we planned to deliver that?
@@ -251,7 +251,16 @@ msg = self._msgobj('msg_01.txt') fp = openfile('msg_01.txt') try: - text = fp.read() + # BAW 30-Mar-2009 Evil be here. So, the generator is broken with + # respect to long line breaking. It's also not idempotent when a + # header from a parsed message is continued with tabs rather than + # spaces. Before we fixed bug 1974 it was reversedly broken, + # i.e. headers that were continued with spaces got continued with + # tabs. For Python 2.x there's really no good fix and in Python + # 3.x all this stuff is re-written to be right(er). Chris Withers + # convinced me that using space as the default continuation + # character is less bad for more applications.
Heh, thanks for the blame tag ;-) All looks fine though. #5612 we didn't touch on though, although I have a feeling we decided to head-in-sand that one for 2.x? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk