[issue1372770] email.Header should preserve original FWS

[Nathan Herring]

Nathan Herring  added the comment:

You are certainly correct about (some, perhaps many) e-mail generators using 
tabs when folding, which is AFAICT, much more likely an incorrect 
implementation of RFC 2822 rather than an intentional transformation of the 
user's specified Subject line. Some*, however, dutifully unfold those tabs back 
into the Subject line, causing all sorts of strangeness -- explosion of 
conversations that are logically identical, except that in one, it's all 
spaces, and in the others, some of the spaces have, seemingly arbitrarily, 
turned into tabs. 

Fixing all of the e-mail generators to Do The Right Thing wasn't what I had in 
mind, but making sure that mailman, a rather commonly used mail service, and 
its reliance on python's Header class, would no longer permute the messages 
made my e-mail generators that do Do The Right Thing, was one step.

I would be inclined to, were I a contributor, make it so that it would conform 
to RFC 2822 unfolding and preserve the FWS accordingly. I don't know if there'd 
be enough desire for your alternative, but if there were, I'd make it a 
non-default option to de-tabify Subject lines (or other headers).

As it stands, I am newly freed from any restrictions from contributing, and so 
I might try and see what mailman's intentions are surrounding taking updates to 
python before trying to propose a patch that they might never use (i.e., they 
may just take the version you're working on now.)

*Microsoft Entourage (which I worked on while at Microsoft) and Microsoft 
Outlook both behave correctly, as far as I could determine in '05, with regards 
to the folding/unfolding headers.

--

___
Python tracker 
<http://bugs.python.org/issue1372770>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25669] unittest.assertEqual() on un-equal types inheriting from collections.Mapping

[Nathan Herring]

New submission from Nathan Herring:

We have some code that generates objects that inherit from Mapping that are not 
nearly as straightforward to instantiate in a test. It's much easier to have 
something like the follows:

foo = … # some collections.Mapping subtype
self.assertEqual({'key': 'value'}, foo)

unittest/case.py's _baseAssertEqual will print out both sides and let me do 
visual inspection, but I'd prefer it if it knew both sides supported Mapping 
and in the != case, performed an analog of assertDictEqual so I could just get 
the keys/values that were mismatched, especially in the cases of large 
dictionaries.

--
components: Tests
messages: 254902
nosy: Nathan Herring
priority: normal
severity: normal
status: open
title: unittest.assertEqual() on un-equal types inheriting from 
collections.Mapping
type: enhancement
versions: Python 2.7

___
Python tracker 
<http://bugs.python.org/issue25669>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25669] unittest.assertEqual() on un-equal types inheriting from collections.Mapping

[Nathan Herring]

Nathan Herring added the comment:

FWIW, it's also pretty easy to write

self.assertEqual({'key': 'value'}, dict(foo))

and get the right behavior, but it'd be nice if it was done automagically by 
type checking.

--

___
Python tracker 
<http://bugs.python.org/issue25669>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com