[Python-checkins] r70772 - in python/trunk: Doc/library/email.header.rst Lib/email/generator.py Lib/email/test/test_email.py Lib/email/test/test_email_renamed.py

[Chris Withers]

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