contrib: have check-code look at files in latin1 instead of ascii This way all files open. So far none of our patterns look like they'll care. Differential Revision: https://phab.mercurial-scm.org/D4249

tests: port inline extension in test for beautifygraph to Python 3 test-glog-beautifygraph.t now passes on Python 3. Differential Revision: https://phab.mercurial-scm.org/D4247

beautifygraph: use slicing instead of subscripting on bytestr Differential Revision: https://phab.mercurial-scm.org/D4246

beautifygraph: use sysstr for checking encoding._wide # skip-blame just an r prefix Differential Revision: https://phab.mercurial-scm.org/D4245

stringutil: have buildrepr delegate to pprint for unknown types This stabilizes some revset reprs across Python 2 and 3. Differential Revision: https://phab.mercurial-scm.org/D4244

stringutil: teach pprint about sets This is the old (Python 2) way of printing sets. I actually prefer the Python 3 version of the repr, but this will result in less test churn in the short term. Differential Revision: https://phab.mercurial-scm.org/D4243

parser: replace bespoke _brepr with stringutil.pprint Differential Revision: https://phab.mercurial-scm.org/D4242

mq: use stringutil.pprint instead of pycompat.byterepr Resolves a few output changes on Python 3 in test-mq.t, and gets us two new passing tests. Differential Revision: https://phab.mercurial-scm.org/D4248

tests: remove expected output of test-parseindex2.py Everything uses unittest idioms now, so this can go away. Differential Revision: https://phab.mercurial-scm.org/D4185

parsers: adjust pure-python version to mimic a3dacabd476b This was caught by the tests, to my surprise. I'll also follow up with a test of the index[-1] behavior so we can be sure that remains consistent, as I think that currently has no coverage. Differential Revision: https://phab.mercurial-scm.org/D4183

tests: restore Python 3 compat in test-parseindex2.py I think this was previously getting lucky in Python 3, and would have stacktraced if something failed. Now that failure messages are eagerly computed, this turned into a problem. Differential Revision: https://phab.mercurial-scm.org/D4182

tests: port remaining bits of test-parseindex2 to unittest asserts Differential Revision: https://phab.mercurial-scm.org/D4181

tests: allow more detailed error message from re.compile test-grep.t now passes on Python 3. Differential Revision: https://phab.mercurial-scm.org/D4240

grep: include format string in columns list This lets us correctly use %d as needed. Differential Revision: https://phab.mercurial-scm.org/D4239

grep: coerce username to bytestr, not str Differential Revision: https://phab.mercurial-scm.org/D4238

grep: difflib sequencematcher opcodes are native strs Differential Revision: https://phab.mercurial-scm.org/D4237

tests: allow for a bonus newline in base64'd email payload Python 3 adds this newline, which is harmless. test-patchbomb.t now passes on Python 3. Differential Revision: https://phab.mercurial-scm.org/D4234

mail: be more cautious about bytes vs str for py3 compat It's suboptimal that we get a bytes on 2 and a unicode on 3, but it's easy to work with and I'm disinclined to change anything unless we start using some sort of type inferencer. Differential Revision: https://phab.mercurial-scm.org/D4233

patchbomb: use native strings when determining attachment disposition Differential Revision: https://phab.mercurial-scm.org/D4232

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

patchbomb: python 3 really wants those email addresses in unicode At this point, test-patchbomb-tls.t almost passes on Python 3, but I'm not really sure what the issue is: we just get a `abort: Connection unexpectedly closed` that doesn't make sense to me. Differential Revision: https://phab.mercurial-scm.org/D3957