mail: always fall back to iso-8859-1 if us-ascii won't work (BC) It looks like this was a well-intentioned backwards compat hack for previewing the output of `hg email` in a stable way. Unfortunately I think this hack's time has come, because Python 3 does a much better job of ensuring it actually emits *valid* email messages. In particular, Python 2 would blindly trust us that the bytes we handed it were valid for the encoding we claimed, but Python 3 has some more sniff-tests that we end up failing. As a result, if we're going to print an email to the terminal, try us-ascii first, but if that fails go straight to iso-8859-1 which should be reasonably readable for ascii-compatible patch bodies. This *will* be a breaking change for ascii-incompatible textual patch content, but I don't think that's avoidable if we want to continue using the email library from the stdlib. .. bc:: Emails from the patchbomb extension will always be printed as though they are iso-8859-1 if they're not valid us-ascii. Previously, previewed emails were always claimed to be us-ascii and might contain invalid byte sequences. Differential Revision: https://phab.mercurial-scm.org/D4231

tests: put some Python 3 polish on inline Python invocations A couple of these became inline python sessions because they got more involved, and one of them is super-annoying and writes directly to sys.stdout.buffer because I just couldn't make it work any other way. Differential Revision: https://phab.mercurial-scm.org/D4230

patchbomb: don't unintentionally duplicate headers This dict-like of headers is only mostly dict-like: if you set a key that already exists, you it appends another value, rather than replacing the one that was already present. This fixes test-patchbomb-bookmark.t on Python 3. Differential Revision: https://phab.mercurial-scm.org/D4229

patchbomb: use sysstrs when describing content-type Differential Revision: https://phab.mercurial-scm.org/D4228

patchbomb: use native strs for email header keys and values Differential Revision: https://phab.mercurial-scm.org/D4223

patchbomb: use email.encoders instead of email.Encoders No idea when this became a thing, but it exists for me in both 2.7 and 3.6. Differential Revision: https://phab.mercurial-scm.org/D4222

mail: properly handle email addresses typically being unicodes Visible progress in test-patchbomb.t on Python 3. Differential Revision: https://phab.mercurial-scm.org/D4221

tests: fix Python3 issues in Python one-liners in test-patchbomb.t # skip-blame just byte prefixes Differential Revision: https://phab.mercurial-scm.org/D4220

dummysmtpd: accept additional kwargs from stdlib smtpd This was causing extremely mysterious failures because smtpd is implemented using asynchat, which in turn doesn't appear to do anything *remotely* helpful if an exception occurs. # no-check-commit because I'm editing a foo_bar function signature test-patchbomb-tls.t now passes in Python 3, but only because it doesn't check message bodies like test-patchbomb.t. test-patchbomb.t is *full* of doubled headers in the output (eg [0]) which seems like an odd failure mode. 0: @@ -141,12 +154,17 @@ MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit + MIME-Version: 1.0 + Content-Type: text/plain; charset="us-ascii" + Content-Transfer-Encoding: 7bit Subject: [PATCH] bookmark X-Mercurial-Node: 8dab2639fd35f1e337ad866c372a5c44f1064e3c X-Mercurial-Series-Index: 1 X-Mercurial-Series-Total: 1 Differential Revision: https://phab.mercurial-scm.org/D4219

mail: fix debug print, which appears to have been broken for a long time I noticed this when trying to debug very mysterious dummysmtpd problems. It turns out you can set self.debuglevel to a number greater than 0 and have smtplib print helpful debug output, but this output on our side of things was broken. Differential Revision: https://phab.mercurial-scm.org/D4218