[PATCH] py3: handling .iteritems() vs .items()

Matt Mackall mpm at selenic.com
Tue Jun 7 16:04:04 EDT 2016


On Tue, 2016-06-07 at 12:05 -0700, Gregory Szorc wrote:
> On Tue, Jun 7, 2016 at 8:23 AM, Jun Wu <quark at fb.com> wrote:
> 
> > 
> > Excerpts from Martijn Pieters's message of 2016-06-07 14:26:59 +0100:
> > > 
> > > On 7 June 2016 at 02:18, Gregory Szorc <gregory.szorc at gmail.com> wrote:
> > > > 
> > > > If it gets accepted, I would propose extending my custom module loader
> > on
> > > 
> > > > 
> > > > Python 3 to rewrite source code to accommodate API differences like
> > > > items/iteritems and range/xrange. See e.g.
> > > > https://hg.mozilla.org/users/gszorc_mozilla.com/hg/rev/7b72cfda136e
> > > > 
> > > > This would mean keeping the source Python 2 compatible and rewriting
> > > > "iteritems()" to "items()" on Python 3. This will require implementing
> > > > items() on our custom classes. I think that is a lesser evil than
> > trying to
> > > 
> > > > 
> > > > figure out when we should use one form or the other in our source.
> > > I'd be uncomfortable with that; this is becoming a tad too much magic.
> > I think it's less magic if there is a tool to print out the transformed
> > code.
> > 
> We could provide a debug command or script to do this.
> 
> 
> > 
> > 
> > IIUC the goal here to have py3 literal fixups as less as possible so things
> > like the annotation information will remain clean. From this perspective I
> > support rewrite iteriterms etc. in the module loader. Things like
> > CoffeeScript and LESS etc. are doing much crazier things and people use
> > them.
> > 
> I agree we should minimize the number of transformations. I still consider
> the entire approach a giant hack.
> 
> JS tools can get away with more because they have source maps that allow
> debuggers and other tools to map final source to original source. AFAICT
> such a thing does not exist for Python. FWIW, the "inspect" module's
> functions for obtaining source code (which are used by e.g. pdb) do things
> like assume source exists on files on disk. At Mozilla, we have some
> processes that import Python modules from Mercurial repositories and we had
> to monkeypatch parts of inspect to play nicely. The takeaway here is
> everything is a giant spider web and it is best we keep automagical source
> transformation to a minimum.

The three big transforms I'm aware of are:

- byte string literals (thousands)
- items vs iteritems (hundreds)
- range vs xrange (we've dealt with this by patching Py3 built-ins)

These are all very formulaic and wide-spread in the codebase. The first one is a
huge huge deal in terms of churn and maintenance effort, so piggy-backing the
second one onto it seems like a pretty straightforward win.

-- 
Mathematics is the supreme nostalgia of our time.



More information about the Mercurial-devel mailing list