view tests/seq.py @ 39037:ede768cfe83e

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
author Augie Fackler <augie@google.com>
date Thu, 09 Aug 2018 21:04:15 -0400
parents 08b8b56bd2e8
children 0605726179a0
line wrap: on
line source

#!/usr/bin/env python
#
# A portable replacement for 'seq'
#
# Usage:
#   seq STOP              [1, STOP] stepping by 1
#   seq START STOP        [START, STOP] stepping by 1
#   seq START STEP STOP   [START, STOP] stepping by STEP

from __future__ import absolute_import, print_function
import sys

if sys.version_info[0] >= 3:
    xrange = range

start = 1
if len(sys.argv) > 2:
    start = int(sys.argv[1])

step = 1
if len(sys.argv) > 3:
    step = int(sys.argv[2])

stop = int(sys.argv[-1]) + 1

for i in xrange(start, stop, step):
    print(i)