[PATCH 7 of 8 v2] python3: handle range/xrange divergence

[Gregory Szorc]

On Thu, Mar 31, 2016 at 4:36 PM, Matt Mackall <mpm at selenic.com> wrote:

> On Tue, 2016-03-29 at 23:33 -0500, timeless wrote:
> > # HG changeset patch
> > # User timeless <timeless at mozdev.org>
> > # Date 1459272984 0
> > #      Tue Mar 29 17:36:24 2016 +0000
> > # Node ID 7049e93dc5766ba35e91fd15755f4c5a899bfcc0
> > # Parent  d90f8d4c6cbaa4046a2b3a242010defefd24dc25
> > python3: handle range/xrange divergence
>
> Sorry, but this is too much. I'm going to drop these.
>
> The absolute_import stuff we've been doing is ugly, but tolerable. But
> having a
> growing stanza of Py3 compatibility hacks at the top of every file is not.
> For
> something as pervasive as xrange (or byte strings!), it's simply not an
> acceptable level of impact. Py3 support is like an unemployed cousin we're
> letting crash on the couch: we're already annoyed that it's here, so it
> should
> try not to stack up dirty dishes everywhere.
>
> Alternate solutions:
>
> - cStringIO -> util.stringio
> - Queue -> util.queue
> - urllib.foo -> url.foo
>

I agree that Python 2/3 shims should live in util or a similar module (like
py3kcompat.py, which I just noticed appears orphaned and unused since we
removed 2to3 support, which is where it was getting injected).


> - __builtins__.setdefault("xrange", range)
>
>
I'm not a fan of mucking about with stdlib modules.


> Also, the check-py3-compact test is nice, but should not be seen as a
> substitute
> for check-code rules, because the latter provide valuable replacement
> advice. So
> these sorts of things will also need check-code rules.


As the person who wrote check-py3-compat, I completely agree. I originally
made it its own test because it was a niche thing and I wanted people
working on Python 3 to have a single place to go to view and manage porting
progress.

These recent patches from timeless represent a shift in Python 3 porting.
Before, we were making changes to things like absolute_import and
print_function that had their own advantages independent of Python 3
(although the main reason for doing them was Python 3). (absolute_import
gave us an excuse to establish a sane module import convention and print()
is more powerful than the print statement.) Now, we're making changes that
serve no purpose other than Python 3 support. These changes are much more
invasive. They also require developers to have some working knowledge of
differences between Python 2 and 3. I think this shift is the appropriate
time to start capturing things like range/xrange and items/iteritems in
check-code rules.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160403/0f7aed9b/attachment.html>